Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call - TEA attribute
Susan Hares <shares@ndzh.com> Fri, 08 April 2022 22:05 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743ED3A18DF for <idr@ietfa.amsl.com>; Fri, 8 Apr 2022 15:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.808
X-Spam-Level:
X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 mwzoLe8wn7QP for <idr@ietfa.amsl.com>; Fri, 8 Apr 2022 15:05:33 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2062b.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eab::62b]) (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 49C263A18DC for <idr@ietf.org>; Fri, 8 Apr 2022 15:05:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HnfOsdopXfQ9AgSjnfbMmwNOXvaTJKKJ2qbWIcCmxINgGZa/H+LUSv3WdghqhfQFgfR7ajo4JKdiERpjqliZweHjsbpp+AQ5355IByw847W+4pL2hy7YDV+dg+vKyVsWyiEcqtDYl9WpHPwTcm+KetTQtTTj9HIj4T8HAX9rUzO6tH7noxrWVnKwWxM86aXJyeCaBKGlJwdtabCkpdLs1xp8J9vzOrFnqEyTwEDraRNS6nrPdS3h/ItyHU7SBEx9Ayt+85KvhZnaV5jDX1O+fgI5S287HVmEIsfbNHs2wv11eE1gKDHOp3i6/VIxhyE0BbqE9wfWv9PTyTAZ+w8u7A==
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=CnFxhl2C0MMCFsblZreanEVfLcsH60ax8f2ephhNzb8=; b=W6Wy+hpMxATPlPEmdbpG+BiQzPqNpCbpBjvPwCs1Bn/RRZfMQWbt9mbeWY3YXqWOA0BAr4ZuJpi/RSkNWVKsGEY0kEqXRmGf4uwofZ72pk9VFkfHL5t7sRPFNuIi3cNf+NxSC+tTzc90EDm4CPjJHCYlDk0DMwqSN66VRqNMKpMFnewQHrBSrDgCOEfHLLbPdmSjS+7Y7l6Z3tdGKpyK6WD8wtpO+lMNfzEbMNcDbTjSeR+UDFwU0LmtRc+9az0muXxkWSAdv7dB7At/zsHUwXyLDjw2pi2t1dRrpsFUctxT3uqKs2AAQjKxuULa0hv38h995iazii5XuPbVg/xZAg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ndzh.com; dmarc=pass action=none header.from=ndzh.com; dkim=pass header.d=ndzh.com; arc=none
Received: from BYAPR08MB4872.namprd08.prod.outlook.com (2603:10b6:a03:70::17) by DM6PR08MB4316.namprd08.prod.outlook.com (2603:10b6:5:a4::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.26; Fri, 8 Apr 2022 22:05:27 +0000
Received: from BYAPR08MB4872.namprd08.prod.outlook.com ([fe80::f510:ab5d:2f54:cc24]) by BYAPR08MB4872.namprd08.prod.outlook.com ([fe80::f510:ab5d:2f54:cc24%3]) with mapi id 15.20.5144.022; Fri, 8 Apr 2022 22:05:27 +0000
From: Susan Hares <shares@ndzh.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call - TEA attribute
Thread-Index: AdhJQAVq545WacCQQv6zJfGNgTmswAAiSERAAG/JamA=
Date: Fri, 08 Apr 2022 22:05:26 +0000
Message-ID: <BYAPR08MB48721135E257AFF7D1565476B3E99@BYAPR08MB4872.namprd08.prod.outlook.com>
References: <012001d84949$ccebb7f0$66c327d0$@ndzh.com> <BL0PR05MB56526B65903472E37C2ACF84D4E69@BL0PR05MB5652.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB56526B65903472E37C2ACF84D4E69@BL0PR05MB5652.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ndzh.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 19e1e91f-a11b-4cd4-a750-08da19abe35e
x-ms-traffictypediagnostic: DM6PR08MB4316:EE_
x-microsoft-antispam-prvs: <DM6PR08MB4316DE23DA41D08E61B8BAA7B3E99@DM6PR08MB4316.namprd08.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: CslNygyArxYXs10OXkAqDKBKsZc+T22o3h5s5lV6pQIA7OAVNRIkVhloEpim7WJVppeeBIppokUfT1hQG0dYgJWBM/Y4eBUwCWLvMktKiK+7i5ZSLIbXRhpO7Ga97G7cakBzrXSFFBSXzAcblYTVDR8MAb8XZuyxIxfxYh9mSxyOaqXDE+UbDb5QRfuntEuLd8lq4GKqlKGJwpCKeumvAzBR1TWcbNLOttC5f5xJgXAWdFySKHqZgumW5Rjax32eWrEUp9cBVENBasUaFWWSZ4DhAFWac+JVMerdolR7JFOvRzKLBkPe6D//AVuSBHfQaJV6rZRjWok6vPdWrlr5XzlsRQTB09OwSwjvzfrjpT76uDQcQlqFLcG6XbUJMUDbWyAZgTf2q4Bk94ON/gbtsvDHmIC7zQm8NinvV59ibOpB19yukIgu/0+ZEsSHpw5yTtHRLXMMbLl6rm78OxM29R95+/l8irEVZbpH3L06jXE5YF+vtI+38H8M3zNP8ZDQMUbj4OUWVMQb9Vyr957rF1oH3AEs2R8PrFg8ARXqQADSS1eE2s5VwtI0pKIom4HiIB4/75W+7BkKK3n16+RLiS6XZ/7CsOPp+8mXQsQAfJ0dt+AfcOcxTCN0wKzYNJMluREhXbBn6+Wy00mfxDGtf0CL1posr7JBXFbzevL6dt8qZN8QuqKmGzK2Lz+lv19lx6RAaL0tRrjPB8yfHlxux6McArllIGACkHEnyqLpMbEirWOmq4L/umBluG5REswTcKgSmF2DKHNbumgcSTQYUrCmmb4pf3x1uYXbRFzICn8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR08MB4872.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(136003)(376002)(34096005)(39830400003)(366004)(396003)(346002)(39510400003)(84040400005)(66556008)(66446008)(38070700005)(8676002)(66946007)(64756008)(76116006)(86362001)(66476007)(2906002)(8936002)(166002)(122000001)(52536014)(38100700002)(30864003)(26005)(966005)(186003)(7696005)(53546011)(55016003)(6506007)(5660300002)(9686003)(71200400001)(110136005)(508600001)(40140700001)(33656002)(83380400001)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 3zXzq7fzKocsvQAYQ83EcShF76GLvIwHbtXdX7NunIJ7IjrwEvuqoMtNMISWTvW0rLV1+7nqqI0kwrqs9zcv8OQ28owItbOQswNToomoJGDam4vEQpUQiuppLwwSmFrLW1DDLGhu70ttbW5iqxb4Y6IRLbQd5nDiTH0e+d1/pfy5CfjzUjAPyn9Tx7KEPeH9Q7injG4zJxoe2UddW7OcWVNtH1efHCFvW4eYu9o2RdPLnr0g9JhjpA9ax2+1vrkyTnInaUmU1Ti8tjQtapsFWSKN2CIp/YaV72A6YhhyMgboONqawYnpSa3Dbbt/G2Z5dkrkYg4YZ/Rus9NoIOlHuhbGmM/kWDqRAtRXAXg4T7fcODRoCbyS+Arwoi7hZqA/38shlJH6sehf1GD0s/rdPeTuIW3Q+eEr8b3ZfGh1hgeTK2wCw+d/Adq/moGIYtYTsGnUtOqA6nNy6SIZEQXz87yGu1NM7l5qWce6fmA2WUTto0+ouDvi0NC9VZZ8FxPUs83bGv3GbqxlJAvhrRehgyL9LZGyNF4mFWUUJmYp8POG9gOtcETB4mTmBzeVBZwJiTyyBNUU6YJj9eTIMd5OdZYyZSKQiTpFwW2vov0PtL0D87M5OiKIHT0/AvAgLd6GqN5H0BFROV6tICHJvZkPzzlT5q5CiA1FyvTX4+G/B5taQjm+BKTJm/OWm05pktExBIGYxTVQ4CQh3fJmYNHbEcgS4etPBgBZ/He1woe+A/sm3Ck5PYEMCU2pL6SkovkDi7OAh45njaYIrBw1mtdMN5wh4WH3E5t4VXHZB57cuIYNrW6qXFNYxmwBPaemo7IFSkFpEKzvbn44SZ+nD+fN7iTbnwhD6kbJlI92uxy9pi2Ua3tBzWoB+xo7vJhiFPCUhqr+SFrjHTW+eXvknj2ZHb/bBoWTi918qdYzR6AVm7pEb9gMyk74M1vixq3UVFCFKI/hf5KozHeUukYu/KkkLcLVEs2SuZgWlIhyomRqJ4eozJzNDMNGQDRBuwZPQVopNgT731t7mWBIhclu9zyRdzNA7Gam2fKUQdcP5wIF28UGyYBMvwwKw/I9CMQQGXNvQ5o+qo8OumQ0qKGqtkv/Av+Y5E91TilL3ycZ4dIa21z01/wCSDhaMcWIcR6hJAg6R+x0rtpbFpf/E4pMVGeXBBjNt52GDiHcUolxlj1F8OKDOX0T1taXLpDdd8iQ3IUbcbTp34NnYczh8TOpHxwo+as11JYBZ9772EEhVleMyFMju3u0aUt8LbSdO4oFtWYJE8jttlQ3ihveqTxjkNUqCNiLgl+zBWHKjF99RMux5HViS7HMY4ddaehlkWlIrEYC/ffwfzXs5wYTUEmuhTFN8A/V0AfbzzZXlZbNjfAHny2aSYBSu85m0yr0TI8iYtB0hymb6rRmmAkDDrYbpjeZ/9WPGBDjfVkHzaW8cOf9y5dptUYFzCzkn0dxSjx6Lh8I/53Z5BBcnt5BVRgQQEyG6YYxBQrS+BH6SMLc/T4KFpoNLJFTehbWJeIaGcjtw7IzNzWfMTTRotlUwpswslLgAmc58F41SZBUKqxM56Ug/Qz7/SG/Qq7TPFwLN5E7J6+XxEhjepQvqXwo+nwW1Io2ThclXKlhalfj2a9EzqIeYKvQcM1UxzIjcwSwswgzRTtojHJe60uZJM6pRYXawQJPUgi5GnG4g8QkBsP3/dTN5nrJ1xjJ8eFPpjulumWdt9mb
Content-Type: multipart/alternative; boundary="_000_BYAPR08MB48721135E257AFF7D1565476B3E99BYAPR08MB4872namp_"
MIME-Version: 1.0
X-OriginatorOrg: ndzh.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR08MB4872.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 19e1e91f-a11b-4cd4-a750-08da19abe35e
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2022 22:05:27.0142 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d6c573f1-34ce-4e5a-8411-94cc752db3e5
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yMUJmSVnPNp3ptOD2Bj8nfW9oO14JD3OaixdQQtc1N27UqQh/EiTMWco80uHXEUD
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4316
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-L5jqeu77-wODyUdRE1nBfoJboc>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call - TEA attribute
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2022 22:05:39 -0000
Jeffrey: See comments below IDR is interested in the clear definition of the BGP TEA + NLRI. I find both drafts need to have clear definitions of: a) BGP Tunnel Encapsulation (RFC9012) definitions b) what NLRIs are supported c) Error handling d) BGP scaling properties Once we get to these things, then it would be important to look at use cases from operators (5G or other) looking to deploy these multicast applications to determine if error handling and scaling works. After we the basics of BGP mechanisms, then we need PIM + BESS review to make sure MVPN works well with SR. Sue From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Wednesday, April 6, 2022 11:05 PM To: Susan Hares <shares@ndzh.com>; idr@ietf.org Subject: RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call - TEA attribute Hi Sue, Please see zzh> below. Juniper Business Use Only From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Susan Hares Sent: Tuesday, April 5, 2022 8:04 PM To: idr@ietf.org<mailto:idr@ietf.org> Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call - TEA attribute [External Email. Be cautious of content] Jeffrey and Hooman: This adoption call runs until 4/8/2022. The reason I have extended the adoption call is to determine what interaction there is between draft-hb-idr-sr-p2mp-policy-04.txt (which has interest in IDR) and draft-ietf-bess-bgp-multicast-controller-07.txt (adopted by BESS). I need your input on these questions in order to advise BESS, PIM, and IDR WG-chairs + WGS on the status of these drafts. Please let me know if I am Unclear on my questions. This is the first of 3 lengthy technical messages. You indicated in https://mailarchive.ietf.org/arch/msg/idr/8k4Pkcg0aqIwPFbSULXepsaHDSw/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/8k4Pkcg0aqIwPFbSULXepsaHDSw/__;!!NEt6yMaO-gk!WSzsQHy_SUQ2pW3C3graivvjrJLm2JLEVtUPyAYkHx-uuWaJLG17XPp60NV8pr-N$> "When it comes to SR-P2MP state downloading, there are three aspects involved here: 1. NLRI to encode policy information 2. NLRI to encode <tree/path/instance, node> identification 3. Tunnel Encapsulation Attribute (TEA) that encodes actual replication branches The draft-ietf-bess-(even when used for SR-P2MP) is aligned with other non-SR multicast trees (IP/mLDP) for a unified approach, while draft-hb is aligned to unicast BGP SR policy." This post examines the TEA attribute discussion in section 3.1 of draft-ietf-bess-bgp-multicast-controller-07.txt draft. Section 3.1 specifies two types of tunnels for TEA (RFC9012): any encapsulation (3.1.1) and load balancing (3.1.2) Zzh> These are two new tunnels (that are SR-agnostic); other existing tunnels can also be used. Zzh> I now realize that I missed listing an SR-specific tunnel type "Segment List tunnel" in this section. It is discussed in section 3.4.3.1 and in the IANA section. [Sue-2]: a) Your text should specify which AFI/SAFI's these two new tunnel types can be attached to b) Your text does not describe which other tunnels can co-exist with these 2 new tunnel types. Please add a complete list to your draft. Zzh> Let me refer to draft-ietf-bess-bgp-multicast-controller as draft-bess, and refer to draft-hb-idr-sr-p2mp-policy as draft-hb. plus interactions with PMSI (section 3.1.3), and zzh> There is no interaction with PMSI. Section 3.1.3 mentioned S-PMSI route because of this: zzh> the bgp-multicast draft is about hop-by-hop signaling and it uses S-PMSI route to signal state for MP2MP upstream traffic, but the bgp-multicast-controller draft does not use S-PMSI route as the Replication State route can be used to signal state for both downstream and upstream traffic. [Sue-2] Are you implying interoperability with the S-PMSI route in the text: "Since different upstream and downstream labels need to be used, A new "Receiving MPLS Label Stack" of type TBD is added as a tunnel Sub-TLV in addition to the existing MPLS Label Stack sub-TLV." If so, please define the interoperability clearly in your draft with an example. If you are not describing interoperability, what is the new sub-TLV used for. 4 Sub-TLVs. In section 3.4.3 you provide signaling for the Policy to enter this tree, but you do not indicate how the two different tunnel types interact with the tunnel types defined in draft-ietf-idr-segment-routing-te-policy-15.txt zzh> The "anyencap" and "load-balancing" tunnel types are not related to draft-ietf-idr-segment-routing-te-policy at all. [Sue-2]: Then what does this text refer to in 3.4.3.1 "In this method, a TEA with tunnels being replication branches as specified in earlier sections Can be used just as in non SR-P2NP?" You must specifically define the Tunnel types and NLRIs your use of TEA applies to. Zzh> The "segment list" tunnel "has a Segment List sub-TLV as specified in Section 2.4.4 of [I-D.ietf-idr-segment-routing-te-policy]", as described in in 3.4.3.1. Section 2.4.4 of draft-ietf-idr-segment-routing-te-policy-15.txt contains a new tunnel type: SR Policy and two groups of subTLVs: weight SubTLV and segment SubTLVS (A-K). 1) how do the 3 Tunnel types interact? (all encapsulation, load balancing, and SR Policy type) Zzh> draft-bess does not use SR Policy tunnel type even for SR-P2MP. [Sue-2] Why are you mentioning draft-hb-idr-sr-p2mp in the text? draft-hb-idr-sr-p2mp specifies: a) New NLRI (AFI=1/SAFI-SR-P2MP) or (AFI=2/SAFI-SR-P2MP) Format: route-type, length, TLVS - with 3 route types (1-3) b) New NLRI is associated with 2 new Tunnel types (P2MP-Policy and Replication segment) Your draft specifies in section 3.3-3.4 a) Tunnel type = Any Encapsulation, Load-balancing b) NLRIs - replication state NLRI (section 3.3) [Not indicated which AFI/SAFI it works for] Replication state (types 1-2) Please include in your discussion where this interaction is Described in the text. 2) How do these 3 tunnel types interact with the PMSI tunnels or Source-Active AD routes (types 1-3), or ASM SPT (type 5) or C-multicast overlays (Type 6-7)? This is (section 3.1.3)? Zzh> They don't interact with those. 3.1.3 does not refer to those route types. [Sue-2]: Are you implying interoperability with S-PMSI A-D routes in section 3.1.3? It is unclear. 3) draft-bess-bgp-multicast-controller states in section 1.7 on sr-p2mp: "An SR- Point-to-Multipoint (SR P2MP) policy is used to Define and instantiate a P2MP tree which is computed by a Controller." Section 3.4.2 defines the SR P2MP policy as BGP Community container in the BGP Wide communities which Contains candidate path preference + TLVS. You state in section 3.4.2 "The replicate state route for replication segments signaled to the root is also used to signal (parts of) the SR P2MP Policy - the policy name, the set of leaves [..optional], the preference of CP and other information". 3a) Are you proposing translating this from the SR Policy or what? Zzh> In draft-bess, we did not define a separate route to encode the policy information. Rather, the policy information is encoded in a wide community that is attached to the replication state route for the tree root. [Sue-2]: Using Wide-Community to attached P2MP Policy is a useful addition to the BGP capabilities. Did you plan an interaction with SR-Policy defined in draft-ietf-idr-segment-routing-te-policy-15.txt? Zzh> In the offline discussion with the draft-hb co-authors long time ago, I did indicate that draft-bess can also take their approach to use a different route instead of using wide community. I alluded to that again in one of the emails for this adoption call. [Sue-2] Routes (NLRI with embedded information) And wide communities have different error handling. Some operational networks prefer one versus the other. 3b) how are the atoms used in the policy? Zzh> A policy has a name and a list of tree leaves among other things. As described in 3.4.2, a string atom can encode the policy name, and a prefix list atom can encode the set of leaves. Zzh> Again, the policy can be encoded in a new route instead of a wide community (to align with draft-hb). [Sue-2] Agreed, the key difference is the choice of error-handling. 4) Give an example of how a simple scenario might be implemented With section 3.4.3.1 and 3.4.3.2? Zzh> Consider a tree node that has two replication branches. Branch 1 is to a downstream node1 with a node sid (label) 101; branch 2 is to another downstream node2 with a node sid (label) 102. [Sue diagram] Node-top (node-3) ==================== SR-1a | SR-1b | SR-2a | | SR-2b (segment routing tunnels) | | | | -------------- -------------- Node-1 node-2 Suppose that the path to node1 does not matter, but to node2 we want to use a particular path represented by a segment list <151, 152, 102>. [Sue- Let's denote SR-tunnel as SR-2b] Suppose traffic sent to this node [node-3] on the tree has incoming tree sid/label 1000, and traffic replicated to node1 and node2 has tree sid/label 1001 and 1002 respectively (the same tree sid/label 1000 could also be used for all incoming/outgoing traffic, depending on the operator's choice - this is discussed in section 1.4). [Sue: I'm a bit confused - so I added the specific identifiers: Node-3 - incoming label 1000: outgoing labels: 1001 toward node-1 on SR-1a and SR-1b. outgoing labels: 1002 toward node-2 on SR-2b, but not on SR-2a [Please let me know if I have this diagram correct] Zzh> With the 3.4.3.1 approach, the tunnel encapsulation attribute (TEA) that is attached to the Replication State route will include three tunnels: Zzh> 1) tunnel 1 for upstream information: any encap tunnel; rpf sub-tlv (to indicate this is for upstream - section 3.1.4); tree-label-stack sub-tlv with label 1000 (section 3.1.5) [Does this go on all 4 SR tunnels [SR-1a, SR-1B, SR-2A, and SR-2B?] Since these are TLVs in the TEA, what AFI/SAFI does this tunnel support? Zzh> 2) tunnel 2 for replication branch 1 to node1: segment list tunnel; segment-list sub-tlv (3.4.3.1) with segment list <101, 1001> [Sue] If there are two branches for node 1, would be receive the same segment list? Zzh> 3) tunnel 3 for replication branch 2 to node2: segment list tunnel; segment-list sub-tlv (3.4.3.1) with segment list <151, 152, 102, 1002> [Sue] My understanding is that 2a, does not have these segments And 2b does. Zzh> With this TEA encoding, the receiving node programs its forwarding state so that incoming traffic with sid/label 1000 will be replicated to two downstream nodes using segment list <101, 1001> and <151, 152, 102, 1002> respectively. [Sue] would you expand this to include 2 SR tunnels from node-3 to node-1, And node-3 to node-2. Zzh> Encoding the upstream information as a tunnel has the advantage that in case of MP2MP, that upstream tunnel will also encode outgoing information for upstream traffic (from tunnel leaves towards root and other leaves), and a downstream tunnel will also have tree-label-stack sub-tlv to encode incoming information for upstream traffic. [Sue]: Yes - but the cost for the P2MP case is more information. The MP2MP versus P2MP has definite trade-offs. Zzh> Section 3.4.3.2 of draft-bess basically says there could be another way to encode the replication information as specified in draft-hb. That section was added as an (unfinished/unsuccessful) attempt to consolidate both draft-bess and draft-hb approaches. [Sue]: I'm glad to hear we have room between the authors to Consolidate on BGP TEA mechanisms and Route Mechanisms. The MP2MP versus P2MP methodology may differ. Zzh> In this example, my understanding of draft-hb approach is that three routes are needed (in addition to the route for the policy information): Zzh> 1) a "Replication Segment Binding Sid" route; its NLRI will encode the incoming SID (1000 in this example). This is specified in 3.1.2 of draft-hb. Zzh> 2) a "Replication segment Route OIF" route (3.1.3) , with a TEA that has a single tunnel of type Replication-Segment-oif (3.2.3) for branch 1 Zzh> 3) a "Replication segment Route OIF" route (3.1.3) , with a TEA that has a single tunnel of type Replication-Segment-oif (3.2.3) for branch 2 Sue: I will ask draft-hb-idr-sr-p2mp-policy authors to confirm your understanding. Zzh> The main difference is that one route is used for each upstream/downstream in draft-hb while in draft-bess, a single route is used with a TEA encoding all upstream/downstream information. I suppose there are pros and cons for each way, and I'll not get into which is better in this email, but one thing to notice is that the draft-hb way is not MP2MP friendly (obviously it is "out of scope" now, but it's good to be extensible). [Sue-2 The MP2MP extensibility via PIM mechanisms can cost more complexity in the methodology. P2MP may be the only function desired by some network operators. What's important now is to have a clear definition of the tradeoffs. Zzh> Thanks. Zzh> Jeffrey Thank you, Sue From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Friday, March 25, 2022 10:47 AM To: Susan Hares; idr@ietf.org<mailto:idr@ietf.org> Cc: 'BESS'; 'pim@ietf.org' Subject: RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call [+ BESS, PIM] Hi, I realized that in a hurry I did not respond to the specific questions below. Please see zzh> next to the questions. Looks like that there are some comments on BESS/PIM list and I will go through those to see if I have any addition/follow-up on those. Juniper Business Use Only From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Jeffrey (Zhaohui) Zhang Sent: Friday, March 25, 2022 6:30 AM To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org> Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call [External Email. Be cautious of content] I am sorry for responding late. I somehow missed this. I think we should discuss the relationship with daft-ietf-bess-bgp-multicast-controller further before adopting this. Thanks. Jeffrey Juniper Business Use Only From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Susan Hares Sent: Thursday, March 10, 2022 10:28 AM To: idr@ietf.org<mailto:idr@ietf.org> Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call [External Email. Be cautious of content] IDR WG: If you just wish to respond to the IDR list, you may respond to this email on the adoption call. Cheers, Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, March 10, 2022 9:55 AM To: idr@ietf.org<mailto:idr@ietf.org>; pim@ietf.org<mailto:pim@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> Subject: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) This begins a 2 week WG adoption call for: draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022) You can obtain the draft at: https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/__;!!NEt6yMaO-gk!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCkFZJodxFk8aTGCpYg34$> In your comments for this call please consider: Zzh> I want to point out that https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!WSzsQHy_SUQ2pW3C3graivvjrJLm2JLEVtUPyAYkHx-uuWaJLG17XPp60HRG_456$> is another way to do the same. I also explained in https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/__;!!NEt6yMaO-gk!WSzsQHy_SUQ2pW3C3graivvjrJLm2JLEVtUPyAYkHx-uuWaJLG17XPp60IkA8lid$> why it was in the bess WG. Zzh> In addition, the bess draft supports *other* multicast trees (IP, mLDP besides SR-P2MP) using a consistent way. 1) Does this technology support the SR P2MP features that distributes candidate paths which connect a multicast distribution tree (tree to leaves). Zzh> It is one way to use BGP to support that. The bess draft specifies another way. 2) Is the technology correctly specified for the NLRI (AFI/SAFI) and the tunnel encapsulation attribute additions (sections 2 and 3)? Zzh> The specified SAFI and tunnel encapsulation attribute additions are one way for the BGP signaling for SR-P2MP. The bess draft specifies another way. 3) Does the P2MP policy operation (section 4) provide enough information for those implementing this technology and those deploying the technology? 4) Do you think this multicast technology is a good Place to start for P2MP policy advertisement via BGP? Zzh> Both ways are good place to start. We just need to figure out how to proceed with the two proposals. 5) Do you think this SR P2MP policies should not be advertised via BGP? Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to discuss the two ways and figure out how to proceed. The authors have discussed before though we have not reached consensus. Zzh> Thanks! Zzh> Jeffrey Cheers, Susan Hares
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Susan Hares
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Jeffrey (Zhaohui) Zhang
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Jeffrey (Zhaohui) Zhang
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Jeffrey (Zhaohui) Zhang
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Jeffrey (Zhaohui) Zhang
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Susan Hares
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Susan Hares