Re: [Idr] [bess] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Thu, 26 May 2022 21:34 UTC

Return-Path: <zzhang@juniper.net>
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 A2DD9C14F748; Thu, 26 May 2022 14:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.672
X-Spam-Level:
X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.575, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=Pi7f45Mu; dkim=pass (1024-bit key) header.d=juniper.net header.b=OJTKri2x
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 IRzVhPuh0W5h; Thu, 26 May 2022 14:34:25 -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 41667C14F725; Thu, 26 May 2022 14:34:19 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24QLIKan012611; Thu, 26 May 2022 14:34:17 -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=6rgKh93E98uZk3ur/OnSdkssgXojs/dHGBfkC94LKsg=; b=Pi7f45MuJQDVDSpX4YvteyQA2r/tC4XS8TgpoxWS4BiKVDGKeQa/OFe7h3VLsrhCQwC4 ZsOg/HsqtLJN4fAKhbqns6IfeetDIMarqwUG68Y2o7DP4GU0iOp1mqGLfYOOt+3lROY2 L76bCEiTRpS+tte5J1mzNq1UKGhHX5erbGNJ4m79FpAuzK9LHc/M9QBBrMOmVruNZlp9 Z44MZtXBpRSuiRgCo4M56ujoS61BkMr4HHWv85epZ6/aTO+9kQ/jHUJlRKg1eVttjJJh 96bv+1bghJ3MVaLmNLmTlx9EKVA21+Mm5rNAGFxaX8zf8zOUE3OnvA064nu6dTUfUIVI ug==
Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2170.outbound.protection.outlook.com [104.47.55.170]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3ga64r1b7a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 May 2022 14:34:16 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iYDRI4SK1JAh2zhZx1YCaj3cIS/qULRx7vpYUJvc5KSN1DgOYyXAanzxOwcabYMWciT/tGhFAbSg7U/VWT8nlsBSq+8f5dUk1eO38HCe8KNQHtAv4RGIj8Hp5SgRxmr811WBnVqbkjIrZVg0BOqczRQCca05Nx179+BhCH67ZIW81Jw6FcHzbSA5BZZuzRYYa66Qd9wKmsr0gGq6731/D4KR1nwLcCFwa2razW9kLYq7VnGtSOranrgr78K8HoeO6kDmvDS+xO+LSzjq4voD49jNdtmQK/baGQN3DyBPPZ2Ffs9fKQE3trV3pp4M6OkR4yMSHa9b9vCtXmzfF7+0bQ==
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=6rgKh93E98uZk3ur/OnSdkssgXojs/dHGBfkC94LKsg=; b=HD8mZ3qWU5lePcakNu7qC6TAfqPFPH9NJa7CLbqVnzt/GtqMAQK9ViSVN0HlgEOMLH60BatXs2p57X35Q8MpuwX+WQldyWmTfFPsvwGdJmodFQW5FxWTwXo2oT2TGUJyV/BNyQScJApgIppMKkCTzbKrT9TOr1umYI11Kn4VIKiIyBRcHBVH3T+wH+J+KqNh2xCsxcRjfm+JUp/95sglOXpiy8A4ECu4LIexoea9m0sz3pshDMk0AQG9HrYhN9Ak2HYGwshOd6mu/ZWdIwt8GYhvHwzhB/0hgDuyvAJJsZ8iu2KN1DKwpJC89u7h1aU0jT8vJ5sDdcQbIDcC32K4Ew==
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=6rgKh93E98uZk3ur/OnSdkssgXojs/dHGBfkC94LKsg=; b=OJTKri2x7ve5Lp6gBW7lq9d1KHf529ogCjOBdFzoIcM/dZLSvLj9VuOCd0YdZ1rqQbsWYBFkCeF8rHnh0q32TwUYgGFlWnOyZDo2eqFUzGj5r3vsf80L/Can18hKG/hcmXaAWp5h3RpcQJUgISnnJRxivZ7ru+MWVTSzRUKL7Yk=
Received: from BL0PR05MB5652.namprd05.prod.outlook.com (2603:10b6:208:6a::19) by SJ0PR05MB7657.namprd05.prod.outlook.com (2603:10b6:a03:2e9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5293.9; Thu, 26 May 2022 21:34:12 +0000
Received: from BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::80a3:3159:9d61:baef]) by BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::80a3:3159:9d61:baef%6]) with mapi id 15.20.5314.006; Thu, 26 May 2022 21:34:12 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: BESS <bess@ietf.org>, "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "pim@ietf.org" <pim@ietf.org>
Thread-Topic: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call
Thread-Index: Adg0k0r8SPpUu5oNRbilwxi9GChogALn6MxQAADh+IAACQ4CcACfNziQACiBqAABawvaMAChcNkAALQBqfADDuVlAAFzUM0wAWQmowABkC5B4AAgwBwAARpl0VA=
Date: Thu, 26 May 2022 21:34:12 +0000
Message-ID: <BL0PR05MB5652C869123DA06C4500C1CCD4D99@BL0PR05MB5652.namprd05.prod.outlook.com>
References: <011e01d83493$6175b310$24611930$@ndzh.com> <BL0PR05MB56524EE412C4938C8083E3BED41A9@BL0PR05MB5652.namprd05.prod.outlook.com> <BL0PR05MB56523E436FBC1353208E9A77D41A9@BL0PR05MB5652.namprd05.prod.outlook.com> <PH0PR08MB6581D4F1DE991EA916BAC91B911A9@PH0PR08MB6581.namprd08.prod.outlook.com> <BL0PR05MB5652FFCF1DAC42EC14831C50D41D9@BL0PR05MB5652.namprd05.prod.outlook.com> <CABNhwV1w7dDxFGchJtT9qb6xcjBBygOkvg42GE3ZAtSp9qg55g@mail.gmail.com> <BL0PR05MB5652ADAFC6E35C0669E321D4D4E49@BL0PR05MB5652.namprd05.prod.outlook.com> <CABNhwV3hT2-tuKm2p6zeaayHEh4nX3GzdUv8ksoggaLLuhZiCQ@mail.gmail.com> <BL0PR05MB565251B4F7D0BBA8BC8FF74FD4ED9@BL0PR05MB5652.namprd05.prod.outlook.com> <CABNhwV1UB4ys31rtLKucNPcwZu5a5d_LOpmKhEMKnkb6h2OJcg@mail.gmail.com> <BL0PR05MB565230BE319181D3E0BDAD01D4C29@BL0PR05MB5652.namprd05.prod.outlook.com> <CABNhwV0GuhBimywuWaVg+u81LX=ZkDHBUUsXWTtCEROmakTvJA@mail.gmail.com> <BL0PR05MB5652E2BF2226E86D3F841B77D4D39@BL0PR05MB5652.namprd05.prod.outlook.com> <CABNhwV3=3+WZVyDZL5k6dRTomsbJz+nu3UNQ_GPxB+NKvDb_FQ@mail.gmail.com>
In-Reply-To: <CABNhwV3=3+WZVyDZL5k6dRTomsbJz+nu3UNQ_GPxB+NKvDb_FQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-05-26T21:34:10Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=337849b3-1656-4707-bd00-f240c046cf01; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a8b92e92-e772-4c30-1104-08da3f5f79ae
x-ms-traffictypediagnostic: SJ0PR05MB7657:EE_
x-microsoft-antispam-prvs: <SJ0PR05MB7657796E2B92AD8D63FD1252D4D99@SJ0PR05MB7657.namprd05.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0/U65hb0ca46Rb1Zi2aIehVoyFADF4C1GCLdSLBazvGhvvpgQcZkDPu+3MBG4oviiqAoV7EiFBss5la2xTJDHWv+zGlPA0Tr16c7JrKsGFHeVCAYHIgUbDCjAw5navwnn1mlEoAT1ZrRpIJC0V1/qZYFr8bf4NCicNBi69nIy5xmQqfmB2bRFenKEI5SnfLND4bQN8HrM45sNo60bovxNUf2N66cxwiqjRVgXxBtNDTrmN4iN/FtP9civDcU9ifvdDiWU0HTgoEL912Zm3wBsJCaZTj8QpR3Mfh0jg5+Bb9Pfgm9IW6Clk+q1NER4ziupm4x6DEF0fLfTrDeqfeaBFx40iRsMZ5y5Z08P3MDMZsTlNxG6/iqCkhWUbPB3Fhzy66Ial6dn8yXUgmJVaXG0TLg2G7i/q1UuNdJL/MckPjJ42OTu4vSOBk8LzJH9FrsAqWgYp0SCYKRjEKqbn4sOu7rjn2UryfpUQRwzmnoJmNTCz5WRBoYYGes4esDRJE8TvZD7NHAPLT+NvF0/QiAV71vqQLOO83KE/bt8Rb87NcdzyvadP92/9E5ekm4dOT1kOvFr1fghPQ5UF6RBRTMag1K/KG3WqsnFTHb1aLJgHJ2V/Km6niVvZh3SzldlnZcP0I3xSc1ZvB83H/nvKvKO5WdS+5dVHrA+tgO14qDXviGzIfKhwh0JdPrJ13LVHqy440CYOnJgkuJMBBzcWWH4dLk55cMrFT9TGeIoCPrK6w78DQE6wBpNMolTW3QcQ3RmIVTDtJw37XsYYJ7H8z7RNv5kX8vhXXaeStIoBfoThU6ZQHJCxilMtTh+11dlaQ+wgecXDcGXsfE9h72HKH7lA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5652.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(166002)(54906003)(966005)(86362001)(508600001)(6506007)(9326002)(83380400001)(52536014)(6916009)(99936003)(53546011)(76116006)(8936002)(316002)(66946007)(7696005)(122000001)(8676002)(66446008)(4326008)(71200400001)(66556008)(64756008)(66476007)(40140700001)(2906002)(186003)(38070700005)(30864003)(38100700002)(33656002)(55016003)(9686003)(5660300002)(26005)(559001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: ydxWI+9iudOqA6n6uLW8geImp+ILp31bkNUyZwGSgpNLCEnm+buzk7+m9CK/2D2u/niO2OGfu4dXy0MZoPnQIaeLL+Vd3Ts6hMEqXvC4er/9xdepdCtIlcsmXss4ifD3GPPQWOtod4Wz8SGGXN3g47HzjwXA2RghyNKPvoFExP2tLw638eYjV+vCsRRR2aYItPzLmQ5n/i+AcFcaGqTtW39D5NZbKP2xgijpbFp4bjZuuNz0FcvidNv4BXkVbJ6wwT8UUoAR/W4rCMMJ8gfg8WibnPzBYYK0/4s5Cb57lbDVYYmq3/CpDAMAM+bMR26fyb5Rph5VCe4TnbRVUBZEGBlO5VAVEjd3/4hAVPfLMyY7VLuVSOykQwGCaQ3JGJMmEZW5jnVQXAaRR3RYNCQmy1pb2Ja0vTaIa+5AbTbMqrvZo0DFyfQo89I3uYrXkm3BHVeqqQLw8UInyGSoH8OgYpy3z75q10wi9P5z9P1ApvEG61bm+CVpLmsYA6IFMxBukaXk9BhKPacyBI21AxVWgyR/I87uHCul2hQFLe2do3ohaorcMWc41q+CRU1uuhwmhKis1pl9NA2Z3EMouNhsWzzbIncE2q5bnLB7xZjOt79yDPrp6p8KJ8I6JuF+q89tCFPOHFn7jLOzLIczv9h649PSB9JDicAZnZuIHoo9WRWIks1QOqUonm5DgPZpY9PzgoA3MYfkHSYUYHQkJ65ZyjQXy9z4tR/P9vFTGsIy9KAPzHi6DDuU6cc+GY3nFGHGn23OylUEUK0t9T0/CSAki2zrDYn3XNioDdA1quNfy1yR7KTmXqDkX5H91ImHrymf+8DqJM+LZrA1TtOg3fHpwOMVuiuv4ILqNATrZToQiD+JwnE+b+/r6OY0UUgTAR1vCQyn1caprmmAN4xf7jHGOqnoLT281TQyEXPO4nN76evhATrQ0eXbsCDZn+44oOPb8t1L3JhhYtgmn1kBIFU/PihJu1L070L4125N9x4CrJcwNW5AD96nUKRwj7fruzQOJbWqEAPeszTzTA6jJl40f9Na/hFMKyvGXxclOFEvmEpL3upMDXMGfzObgQd8i6CRJ8OxOgEu6orf2EsUS5QKC6EGWl51ef9DZw/wbM8NdzOHDDJ3mD308jDQrqBmv9b60YN9652TAXH0RIB9Lg/W3I+Kkx/+bFNRrSGKZsv+nFZHTQplvPACseaY0WxV13lpZrFBYQAC3S+ezCvXHO/4XRhvtMPgU70a7w+Aoaa86XnyarYTFgVx5cnjP5PMMqop42GP8GAN1iCWv42srwjCMTaQoeZHXMfN7hcnNYz3pQwZSnh0SeiClOZMy14ouf0gYgHnugvtSq5oV6vswBv5QWiHCt0oaFHW+Dbm9BH6337ESUubMohqivHkwbEcrg9NvgR6xns9B1enGmsZAG411CU5WkNtUWKcaoPlcIGR+ugbrl5nS7tEvo8QDNESCxYDaOq4xrRTUzxV03f5nuPsiA2Q7lDYTeKBxB9IynKXZp2NO7q2gcwdIHSaZ8jvusz5ZcMxU+yYh074uEtJTfMRKJPyKK/PxwR23vujZ5imToch393xWsrhlUpctK8DMXcW4OzRwt07KJZojsUjVLlSNXsabYhCUYGq3phtEg9s1XovyZuKvpEmKebnzdg33YjTQFLYC62asIcqDRuxn8oo4d9mtEMRqX+F6UyT8AUgV5XlZYraUz1yS7/7rdXIdkELvrzzPpsyZ8wJ4iZuyu2aSw==
Content-Type: multipart/related; boundary="_004_BL0PR05MB5652C869123DA06C4500C1CCD4D99BL0PR05MB5652namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5652.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a8b92e92-e772-4c30-1104-08da3f5f79ae
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2022 21:34:12.1615 (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: DzYkVcTGbuoTE0eOuURbYWQaV//L9EQWgcyElMhNSgRSCexZyS0n+c2XuDmfg8kpMK2YSFGzJAUPC2aMnsneZw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR05MB7657
X-Proofpoint-ORIG-GUID: 6zNFQu9WRhJeoh2U5eyy9KzO-MFfTOJu
X-Proofpoint-GUID: 6zNFQu9WRhJeoh2U5eyy9KzO-MFfTOJu
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-26_11,2022-05-25_02,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 mlxscore=0 clxscore=1011 bulkscore=0 phishscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2205260100
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9AMPOTFP370NAyMbciky-WSKXuk>
Subject: Re: [Idr] [bess] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.34
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: Thu, 26 May 2022 21:34:29 -0000

Hi Gyan,

Please see zzh4> below.



Juniper Business Use Only
From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Saturday, May 21, 2022 2:05 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: BESS <bess@ietf.org>; Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org; pim@ietf.org
Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[External Email. Be cautious of content]


Hi Jeffrey

Pleas see Gyan4>

Kind Regards

On Fri, May 20, 2022 at 10:59 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
Hi Gyan,

Please see zzh3> below.



Juniper Business Use Only
From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Sent: Thursday, May 12, 2022 11:29 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: BESS <bess@ietf.org<mailto:bess@ietf.org>>; Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>; pim@ietf.org<mailto:pim@ietf.org>
Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[External Email. Be cautious of content]


Hi Jeffrey

Responses in-line Gyan3>

On Thu, May 5, 2022 at 9:43 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
Hi Gyan,

Gyan2> What is the advantage of using TEA encoding as opposed to existing PTA RFC 6513 & RFC 6514 MVPN signaling?

This is about using procedures in draft-ietf-bess-bgp-multicast-controller to set up (s,g) forwarding state in a VRF, as an alternative to BGP-MVPN.
 Gyan3> Ack.  I think a drawing of service and transport controller would be good and how that plays into the operator deployment.  Would there  be a corresponding draft in PCE WG for stateful PCE instantiation of the BGP based Trees by the controller?
Zzh3> Will add a drawing in the next revision.
    Gyan4> Perfect!
Zzh3> https://datatracker.ietf.org/doc/draft-li-pce-multicast/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-li-pce-multicast/__;!!NEt6yMaO-gk!Aj1Wmaxo7RsCY0Usz61SzT2jK1vae9WsofYzKp7bylIfQCAbkh9P59QWFarRUQlKeX8QM8yJPR9eAcvIjIriTA$> is the PCE counter part.

    Gyan4> Perfect!
As described in https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09*section-2__;Iw!!NEt6yMaO-gk!D-8-rhn36Jl-nSrpiv0mGDhH00ks-O4MceV0W9g5N73cAE2yvJFaa1mkaZ27Z0bpP8k_fOQTjb2ncW4Fl3rldQ$>, instead of ingress/egress PE figuring out the (s,g) state based on BGP-MVPN signaling and PIM signaling (for local OIFs to CEs), they simply take instructions from a control on what tunnel branches and which local OIFs to use – as if an operator is configuring them statically. This allows the PEs to be very dumb and simple.
    Gyan4> Understood.  Makes sense.

 Gyan3>  So this is simplified MVPN signaling state paired down from RFC 6514 using same RR or eBGP mesh peering single or multi hop using MCAST-TREE SAFI new route types defined in BGP Multicast section 2 carrying the s,g hard state in BGP eliminating soft state, and extends the TEA encoding defined in BGP Multicast to as well SR use cases.
Zzh3> There was no soft state in RFC 6514 anyway.
     Gyan> BGP MVPN P-Tree signaling is hard state with separation of control plane and data plane as compare to PIM ASM, SSM tree building soft state.
The key is that instead of PEs figuring out (s,g) forwarding state based on MVPN routes, they simply take instructions from the controller. Dumb but simple routers with omniscient/omnipotent controllers.
https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00#section-2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00*section-2.1__;Iw!!NEt6yMaO-gk!D-8-rhn36Jl-nSrpiv0mGDhH00ks-O4MceV0W9g5N73cAE2yvJFaa1mkaZ27Z0bpP8k_fOQTjb2ncW6NPliK9w$>
 Gyan4>  As mentioned above a drawing would be most helpful as the transport controller now  sits attached to the forwarding plane with P-Tree signaling relaying instructions to the ingress/egress PEs to build the P-Tree forwarding state.  So instead of the standard ingress/egress PE MVPN state machine signaling, now the controller is in the mix intercepting the P-Tree signaling in-line receiving the MCAST-TREE Leaf-AD route and advertises the MCAST-TREE replication state route to setup the c-multicast from ingress to egress similar to MVPN Auto discovery PMSI-I/S - Leaf AD exchange to build the inclusive / selective tree. So the PEs are dumb down in that there is no Ingres/egress PE signaling, however there is still P-TREE signaling to the controller. So if the P-TREE is not part of an SR policy thus no BSID then the replication branches are encoded in the TEA or otherwise in the BSID which would have the P2MP SID list in the policy which when the BSID is popped by the ingress PE is pushed onto the label stack. So for the mLDP case (non SR) a PTA would be attached to the P-Tunnel on ingress PE with TEA encoding the replication branches would the replication branches be over the provider core not the PE-CE interfaces.  We are talking about the Ingres PE replication branches to the egress PEs so why would the PE-CE interfaces be in the TEA list?  You do mention by doing do we don’t have to specify the replication branches but I am not understanding why.
Zzh4> There is an underlay/transport controller setting up forwarding state for the underlay tunnel across ingress PE, transit P, and egress PE routers. There is also an overlay controller setting up (s,g) forwarding state in ingress/egress VRFs. The two controllers could be the same one. Remember that there are no fundamental differences between the two – both are just setting up tree state on relevant tree nodes. The underlay tree (tunnel)’s nodes are the ingress/egress PEs and transit P routers (specifically in their master/default instance). The overlay tree’s nodes are ingress/egress VRFs (and customer routers if they also use controller signaling).
Zzh4> Not sure what you mean by the purple text above. Anyway, the overlay controller somehow knows where the overlay leaves are (it could be that it received from egress PEs their overlay Leaf routes, or from other means like orchestration) and it figures out where the overlay upstream (an ingress VRF), and figures out what underlay tunnel to use, so it sends Replication State route to the ingress/egress PEs to program (s,g) forwarding state in the VRFs. The state in the ingress VRF would include p-tunnel information and optionally local PE-CE interfaces. The p-tunnel information could be in the following forms: a) actual replication branches (of the p-tunnel) encoded in the TEA; b) actual binding SID (of the p-tunnel) encoded as a one-element segment-list in the TEA; c) a PTA that specifies the tunnel type/identification just like in MVPN PMSI route case (though in this case it is not MVPN PMSI route but Replication State route) and the ingress PE will use the information to find out the p-tunnel forwarding state.
Zzh4> In parallel, the underlay/transport controller would send out Replication State routes to PE/P routers to set up p-tunnel forwarding state.
Zzh4> For the green text: VRF may have receivers on/downstream of the CEs on the other end of the PE-CE interfaces. The overlay controller may know those and program the VRFs with replication branches to both remote PEs and local CEs.
Zzh4> For the red text: notice the replication branches for the overlay state in the ingress VRF could include both PE-CE interfaces and p-tunnel branches to remote PEs. For the latter, please see b) c) above.
Zzh4> Jeffrey
This sentence below is confusing.


   This not only allows provider tunnel without a binding SID (e.g., in a

   non-SR network) to be specified without explicitly listing its

   replication branches, but also allows the service controller for MVPN

   overlay state to be independent of provider tunnel setup (which could

   be from a different transport controller or even without a

   controller).

I think this is what you are talking about related to static setup and we don’t need to specify the replication branches but then how would the P2MP tree be built without it?  I am definitely missing something.

So I think this is the dumb down static nature of the PEs with this controller based setup below.


   Depending on local policy, a PE may add PE-CE interfaces to its

   replication state based on local signaling (e.g., IGMP/PIM) instead

   of completely relying on signaling from controllers.

This last paragraph below is confusing below.

So with the MCAST-TREE SAFI the PMSI-I/S tree is built from Ingres to egress PE by the controller, so you have both the inclusive tree that all PEs are part of the Default MDT inclusive P-TREE and selective Data MDT P-TREE for c-multicast interested PEs.  So it’s local implementation configuration to switch from inclusive to selective tree based on data rate.

So I  would not think the Ingress PE would withdraw the inclusive tree as it’s a switchover from inclusive to selective based on data rate and so some VPNs maybe on the inclusive tree and others maybe on the selective tree.  The inclusive and selective trees are hard state once built and remain permanent for the p-tree p-multicast, however the c-multicast can switchover from inclusive to selective tree based on local configuration.


   If dynamic switching between inclusive and selective tunnels based on

   data rate is needed, the ingress PE can advertise/withdraw S-PMSI

   routes targeted only at the controllers, without PMSI Tunnel

   Attribute attached.  The controller then updates relevant MCAST-TREE

   Replication State routes to update C-multicast forwarding states on

   PEs to switch to a new tunnel.


          3 -  S-PMSI A-D Route for (x,g)

          4 -  Leaf A-D Route

          5 -  Source Active A-D Route

       0x43 -  S-PMSI A-D Route for C-multicast mLDP

So RT-3 4 5 are existing RT from RFC 6514 and 0x43 is a new RT introduced in BGP multicast draft.  Does the controller draft use all 4 RTs and / or are there any additional RT used.   That should be spelled out in the draft all the MCAST-TREE SAFI RTs that carry over to the controller draft.  Also if there are any additional RFC 6514 RTs that are not included in the BGP multicast draft those should be spelled out as well.

Zzh3> RFC 6514 and bgp-mcast use different SAFIs, so the route types don’t really need to correlate with each other, even though the name/number and function bear some similarity.
 Gyan4> Ack
I think the section 3.3 Replication state RT is the only additional to the list

From that point of view, there is no difference between “underlay” and “overlay” and the TEA is perfect to encode that information – each “tunnel” in the TEA is a replication branch.
Gyan3>Ack
That section does have the following that makes use of the PTA (attached to MCAST-TREE NLRIs for programing VRF (s,g) forwarding state):

   The Replication State route may also have a PMSI Tunnel Attribute
   (PTA) attached to specify the provider tunnel while the TEA specifies
   the local PE-CE interfaces where traffic need to be sent out.  This
   not only allows provider tunnel without a binding SID (e.g., in a
   non-SR network) to be specified without explicitly listing its
   replication branches, but also allows the service controller for MVPN
   overlay state to be independent of provider tunnel setup (which could
   be from a different transport controller or even without a
   controller).
 Gyan3> Ack
   In the draft you mention how the draft applies to SR P2MP policy and it sounds like this draft updates the PIM P2MP draft adding the new MCAST-TREE SAFI with procedures where each tunnel in TEA is a replication branch to instantiate the P2MP policy.  So  this draft is an alternative controller based option to building an SR P2MP tree using MCAST-TREE SAFI and TEA tunnel branch encoding as opposed to using Replication SID / Tree SID solution.

Zzh3> PIM SR-P2MP draft is  the “framework” document. An SR-P2MP tree can be set up with different signaling including PCEP and BGP. In the BGP case, the bess draft uses the MCAST-TREE SAFI with the same mechanisms as other tree types, while the IDR draft uses a different SAFI and mechanism for SR-P2MP only. The decision is to separate SR-P2MP out to an IDR draft and consolidate the solutions from the two drafts.
Gyan4> I followed the adoption call results Sue posted so the SR P2MP related content in your BESS controller draft would be ported into the new draft.  So your BESS controller draft would just retain the Non SR P2MP content.
https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-1.7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09*section-1.7__;Iw!!NEt6yMaO-gk!D-8-rhn36Jl-nSrpiv0mGDhH00ks-O4MceV0W9g5N73cAE2yvJFaa1mkaZ27Z0bpP8k_fOQTjb2ncW5JoRSkTg$>



   Procedures in this document can be used for controllers to set up SR

   P2MP trees with just an additional SR P2MP tree type and

   corresponding tree identification in the Replication State route.



   If/once the SR Replication Segment is extended to bi-redirectional,

   and SR MP2MP is introduced, the same procedures in this document

   would apply to SR MP2MP as well.



Section 3.1.1 Any Encapsulation tunnel



So would this controller procedure support I am guessing RFC 4023 MPLSoGRE RFC 7510 MPLSoUDP and

RFC 8663 SR-MPLS over IP as well as SRv6?



https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-3.1.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09*section-3.1.1__;Iw!!NEt6yMaO-gk!D-8-rhn36Jl-nSrpiv0mGDhH00ks-O4MceV0W9g5N73cAE2yvJFaa1mkaZ27Z0bpP8k_fOQTjb2ncW4z2dGotw$>



Maybe listing all the encapsulation tunnels supported and caveats would be good.



Zzh3> Listing them out would be limiting and could soon become outdated. The “Any Encapsulation” name means that it does not matter what base tunnel is used.

Section 3.1.2 talks about TEA enhancements adding load balancing tunnel sub TLV.  Would there also be corresponding update to SR P2MP policy as far as load balancing as load balancing can be configured by the SR policy directly?  What is the interaction between SR P2MP policy instantiation and the TEA encoding of the replication branches?


Zzh3> Do you mean policy on the tunnel root, and the candidate paths in the policy?
 Gyan> Yes.  I do think when the SR P2MP content from your draft  is ported into the new draft, that will keep all the SR related together and will help clarify the overall solution as it’s all in one draft.
SR policy uses TEA already for the policy encoding

https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-17#section-2.4.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-17*section-2.4.4__;Iw!!NEt6yMaO-gk!D-8-rhn36Jl-nSrpiv0mGDhH00ks-O4MceV0W9g5N73cAE2yvJFaa1mkaZ27Z0bpP8k_fOQTjb2ncW73iX1w8g$>

zzh3> I don’t think using TEA to encode policy information is really a good match for the TEA’s original purpose (please see https://mailarchive.ietf.org/arch/msg/idr/p0SkN-O8j5_RLyq_A21uffFZ7RM/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/p0SkN-O8j5_RLyq_A21uffFZ7RM/__;!!NEt6yMaO-gk!Aj1Wmaxo7RsCY0Usz61SzT2jK1vae9WsofYzKp7bylIfQCAbkh9P59QWFarRUQlKeX8QM8yJPR9eAcsrV8_6NQ$>), but that’s water under a bridge now.
    Gyan4> Ack
Zzh3> That explains why the bess draft uses wide community to encode policy information, though I am fine with taking the TEA approach in the consolidated the idr SR-P2MP draft (even though a new BGP Path Attribute would be a better choice in my view).
 Gyan>  I am fine with either TEA or BGP Path attribute but I agree the path attribute is much simpler.
Section 3.1.3 Segment list tunnel

So is something new being added or are we just reiterating section 2.4.4 of SR policy draft.  If nothing is changing and we are using the same sub TLV in SR policy section 2.4.4 maybe state that is the case.  So all the other sub TLV listed in section 3 are all new sub TLV that would update SR policy draft TEA encoding of sub TLVs, correct?  As the SR policy draft is the base draft for SR policy, here with this draft we are extending the SR policy TEA encoding with all the additional TLVs listed.

Zzh3> It’s a new tunnel type defined in this draft but it uses sub-TLVs from the policy draft.
   Gyan4> Ack
Zzh3> Other sub TLVs in section 3 are for this new tunnel type, so they don’t update the SR policy draft.
 Gyan4> Got it
Section 3.1.7 Backup Tunnel Sub TLV

Could this apply to unicast P2P tunnel  and not just multicast P2MP tunnel  for backup tunnel for live-live protection?

Zzh3> Yes, but I’m not trying to assert that in this draft.
 Gyan4> Ack
Section 3.4.2 BGP Community container

SR policy draft does not use BGP Wide communities for encoding.

So this would be something new that we would be encoding the SR P2MP policy using BGP Wide Community new optional atoms TLV.

Could this also apply to unicast SR P2P policy as well?

What is the benefit of encoding the SR P2MP policy  in wide community containers versus encoding as defined in SR policy draft?

https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-17<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-17__;!!NEt6yMaO-gk!D-8-rhn36Jl-nSrpiv0mGDhH00ks-O4MceV0W9g5N73cAE2yvJFaa1mkaZ27Z0bpP8k_fOQTjb2ncW4S-fpInA$>

zzh3> Please see earlier comments above.
Zzh3> Thanks.
Zzh3> Jeffrey
 Gyan4> Thank you
Jeffrey



Juniper Business Use Only
From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Sent: Thursday, April 28, 2022 12:19 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: BESS <bess@ietf.org<mailto:bess@ietf.org>>; Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>; pim@ietf.org<mailto:pim@ietf.org>
Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[External Email. Be cautious of content]


Hi Jeffrey

Please see Gyan2>

On Tue, Apr 12, 2022 at 11:02 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
Hi Gyan,

Please see zzh2> below.



Juniper Business Use Only
From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Sent: Friday, April 8, 2022 8:48 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: BESS <bess@ietf.org<mailto:bess@ietf.org>>; Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>; pim@ietf.org<mailto:pim@ietf.org>
Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[External Email. Be cautious of content]


Hi Jeffrey

Please see Gyan>


On Tue, Apr 5, 2022 at 7:38 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
Hi Gyan,

Please see zzh> below for my view.



Juniper Business Use Only
From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Sent: Tuesday, March 29, 2022 10:31 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: BESS <bess@ietf.org<mailto:bess@ietf.org>>; Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>; pim@ietf.org<mailto:pim@ietf.org>
Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[External Email. Be cautious of content]


Dear authors

Can you describe in more detail the relationship and interaction between the two SR P2MP variants below:

Defines new SAFI for SR P2MP variant
https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3jKh83Sr$>

zzh> draft-ietf-bess-bgp-multicast-controller (referred to as draft-bess) defines a SAFI and different route types of that SAFI to setup replication state on IP/mLDP/SR-P2MP tree nodes. One of the route types is for SR-P2MP purposes.
Zzh2> Correction – the MCAST-TREE SAFI is defined in draft-ietf-bess-bgp-multicast.

   Gyan> Ack
Zzh> draft-hb-idr-sr-p2mp-policy (draft in this adoption call, referred to as draft-hb) defines a different SAFI and route types for the same SR-P2MP purposes.
 Gyan> The adoption call draft is aligned with SR-TE policy as P2MP extension for simplicity for operators which I agree makes sense.
Does this draft utilize all the drafts below Tree sid / Replication sid and SR P2MP MVPN procedures for auto discovery etc.

Zzh> Both drafts are for realizing the two tree-sid drafts mentioned below; both can be used for draft-ietf-bess-mvpn-evpn-sr-p2mp.
 Gyan> Ack
Zzh> As I mentioned before, both draft-bess and draft-hb have its own considerations. The biggest difference is how the replication information is encoded in the Tunnel Encapsulation Attribute (TEA).

Gyan> Ack
Zzh> I can understand that the IDR/PIM/BESS WGs may decide to accept both ways of encoding replication information in the TEA, but I believe we should share SAFI and route types between the two drafts – only the TEA would be different.

Gyan> Both the BESS and IDR adoption draft are vastly different solutions that have very different goals I don’t see any reason or need to have similarities as far as TEA or SAFI encodings or usage.  The BGP controller draft has a very wide scope, but also is more of an alternative approach as it introduces new extensibility idea of utilizing TEA and wide communities encoding to make the solution RFC 6513 and 6514 MVPN signaling independent.  That is a drastic change for scalability for operations traditional use of multicast X-PMSI P-Tree  leveraging the separation of control plane from forwarding plane with RR using traditional MVPN procedures.  As the ideas from the BESS draft as it builds on the BGP Multicast draft is to eliminate soft state tree building protocols and with the move towards hard state, thus the signaling paradigm change from traditional MVPM procedures to alternate TEA and wide community encoding.  Am I reading that correctly as the goals of the BESS draft?

Zzh2> Not really 😊
 Gyan> Ok
The BESS document also mentions that the solution can be used for underlay and overlay trees as replacement for MVPN signaling.  For underlay trees are you referring to GTM?  I have many more questions about the BESS draft and will ask in a new thread.

Zzh2> draft-ietf-bess-bgp-multicast-controller was initially intended to build traditional IP multicast trees (w/o any VPN specifics) and mLDP tunnels (started in September 2017) with calculation on and signaling from controllers. SR-P2MP was added in -03 (July 2020) because the generic mechanism for IP/mLDP trees can be used for SR-P2MP as well. These can all be considered as underlay.
    Gyan> Ack
Zzh2> Overlay support – as an MVPN replacement – was added in -06 (February 2021), but the concept is *not different* from underlay at all – we’re just setting up (s, g) IP multicast state in VRFs, with downstream nodes including remote VRFs connected by some sort of tunnels. That is not different from setting up state in global table at all.

     Gyan2> Ack

   Gyan2> What is the advantage of using TEA encoding as opposed to existing PTA RFC 6513 & RFC 6514 MVPN signaling?
Zzh2> Thanks.
Zzh2> Jeffrey
Zzh> Jeffrey

Defines Tree SID stitching of replication SID SR policy P2MP variant
https://datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3gdi0hAB$>

Replication SID
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3smIMNzh$>

Defines new SR P2MP PTA using MVPN procedures
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3g-W3jH0$>


Kind Regards

Gyan


On Mon, Mar 28, 2022 at 3:39 PM Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
Hi,

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 major difference between the two ways is on #3. Indeed, we could not reach consensus – there are two ways of encoding the TEA and each has its own considerations. The draft-ietf-bess way (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.

I want to initiate a discussion and I can understand that WGs may eventually choose to allow both ways for #3. Even so, I think we should strive for consistent approach at least for #1 and #2 (and for that I am not saying that draft-ietf-bess way must be used). For example, use the same SAFI and route types for both ways, but use different TEA encoding methods.

Thanks.

Jeffrey



Juniper Business Use Only
From: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>>
Sent: Friday, March 25, 2022 11:34 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Cc: 'pim@ietf.org<mailto:pim@ietf.org>' <pim@ietf.org<mailto:pim@ietf.org>>; 'BESS' <bess@ietf.org<mailto:bess@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]

Hi All

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.

HB> yes there was discussion and there was no consensus to merge the 2 drafts as their approach is widely different. The authors of this draft have kept the implementation very close to unicast BGP SR Policy for the segment list, which simplifies the implementation and deployment of the technology. As you said there seems to be two way to download this policy and the segment list and we can work on both.
Given the solid support I don’t see why the adoption of this draft should  be delayed because of these arguments.

Thanks
Hooman

From: pim <pim-bounces@ietf.org<mailto:pim-bounces@ietf.org>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 10:47 AM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Cc: 'pim@ietf.org<mailto:pim@ietf.org>' <pim@ietf.org<mailto:pim@ietf.org>>; 'BESS' <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [pim] [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!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGazDpUZk$> 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!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGW1pXg_c$> 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
_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3t2xHmG0$>
--

Error! Filename not specified.<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3l4bzk3s$>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

--

Error! Filename not specified.<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RiHtqGntIPhoemdxe2yBGpMBQILKyyj3TMv6dkbc_ucJ3OqtTJdthtFCYzd2wPtC$>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

--

Error! Filename not specified.<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Tvnc-w7uwkJv79QNGutNiQGYzxGECmu21Ktr6Gw1Vjj5GqUslaeyHwwia2jlEeSo$>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!D-8-rhn36Jl-nSrpiv0mGDhH00ks-O4MceV0W9g5N73cAE2yvJFaa1mkaZ27Z0bpP8k_fOQTjb2ncW7JJH6AyQ$>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Aj1Wmaxo7RsCY0Usz61SzT2jK1vae9WsofYzKp7bylIfQCAbkh9P59QWFarRUQlKeX8QM8yJPR9eAcsGeBo30g$>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347