From nobody Wed Dec 2 06:10:47 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC743A1412; Wed, 2 Dec 2020 06:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ElOEvG9E; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ECfJYYYf 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 FhWxGR6Kw7W1; Wed, 2 Dec 2020 06:10:42 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2FC3A1410; Wed, 2 Dec 2020 06:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4480; q=dns/txt; s=iport; t=1606918242; x=1608127842; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=nvcoPGD+TlyyxbOH44+W99/Lt83r+5duD3dlMkCT2qU=; b=ElOEvG9EP05O624cXBvYJoSaBqzy5GeH6lh0LHQdYQ0J9TTpt5kGQCKh 78bPC3qX6I4uRc+BYkI9qtfES1zeICkJPEGprw6izbZY0QFsWuitvscGI 0KKbG+v92rSuqbjzJcijmWx2PTAtOWhClqQY20D94LwmGP1SSeJtexRxH M=; X-IPAS-Result: =?us-ascii?q?A0DLCABcnsdf/5JdJa1iHgEBCxIMQIFEC4FSUQeBUC8uh?= =?us-ascii?q?DyDSAONXIoXjnGCUwNUCwEBAQ0BAS0CBAEBhEoCF4F9AiU3Bg4CAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBHGFYQyFcgEBAQQSEREMAQEpDgELBgEIEQMBAgMCJgIEH?= =?us-ascii?q?xEVCAoEAQ0FGweDBIJWAy4BoggCgTyIaXaBMoMEAQEFhRwNC4IQCYEOKoJzg?= =?us-ascii?q?3aBBoVRG4FBP4ERJxyCVT6CG4U6M4Isk0MBPqQjVwqCcpYchRcDH4MhiiGUY?= =?us-ascii?q?pNyjX2OaIQwAgQCBAUCDgEBBYFsJIFXcBU7KgGCPlAXAg2OIYNxilh0NwIGA?= =?us-ascii?q?QkBAQMJfJACAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AD4EdJRBaZkqGS4f9EulQUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00g3JQIzE5vMCgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8bjbkLfozu56jtBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,386,1599523200"; d="scan'208";a="600147329" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Dec 2020 14:10:20 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B2EAKuF029878 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2020 14:10:20 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Dec 2020 08:10:19 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Dec 2020 09:10:18 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 2 Dec 2020 08:10:18 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RbdX8/puRVq4DiPHrXa5Ryj+NNnxn0k5eQSZSb9vSHNocNCn46ptYhpFug+Zj0tv4gvijuZD3ZI0mQmKFuILD5P1GBQBT8usiYx7lamagcJdXSdNiPm9NnJWLQx3Fq8oKLG2e08QvbTDCGeJMBsJbfc9CUzBr3Ol6kjeCaSDaICfUquGQZtYIzzcOB2dNE2Ew0wtcl/UIHtoJgfY2crPLCAO1jTuNhmz8+upfhjwro7VhA2vwscrt7ztBtSdaiUmaL7YuAjkvTuagoGMZhUAQ9Nwltrp/YoLWjkK4TaSYPuGy/rT552PRSmR0EWIDWC08IVjorninaGMDP/bHg+r4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nvcoPGD+TlyyxbOH44+W99/Lt83r+5duD3dlMkCT2qU=; b=RoYBZ7ei3s7qvZV7TgxxWN73awCFUNtGWbfqxMOE+hrKJiP4U4l6Lxw1Jn+BVdapxqHE6lx7p0alf1JPwwgu0V00987XsyJ2+H0RZRAZuCoIkwQwcKUTu11A6+CjCFzge90TlAqow0nG1kNCMe+OVJaTh1MpEqRXLIvfcqOOXWhcioStAjs3vFuGSLwDxgck8pstGs529zDLfBMndnlkv8fWZtLuu/tiQ7nTPMyEt1R6z7XCCmPAMnPSKQuEgfu4IJM5i1OafmgZBU6mhBs/ArwYVz+224Tkeks7knI3QX2e61Kwdb3gYeZ39vB/gUtXg0cfIuLGy95LDsHA3EU6nw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nvcoPGD+TlyyxbOH44+W99/Lt83r+5duD3dlMkCT2qU=; b=ECfJYYYf9XR8+pao069J86us+V/YtWg1JPM3FSx1euk5IvY3+fxuaGb0ipJ45WrNQUn0XC4U/XJGAkpBET/CKT8gX58jVTef1romPB6pclCWpaR8mvYV3QDJzSiSTyVLspgsyO1Pog5m3opdfOdbcBFMe11xxIAPciq8Gf8gUmU= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5175.namprd11.prod.outlook.com (2603:10b6:510:3d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Wed, 2 Dec 2020 14:10:17 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d%7]) with mapi id 15.20.3611.025; Wed, 2 Dec 2020 14:10:17 +0000 From: "Eric Vyncke (evyncke)" To: "Gengxuesong (Geng Xuesong)" , "gjshep@gmail.com" , "Jeffrey (Zhaohui) Zhang" CC: Gyan Mishra , Alvaro Retana , BIER WG , "EXT-zhang.zheng@zte.com.cn" , Tony Przygienda , draft-ietf-bier-ipv6-requirements Thread-Topic: [Bier] draft-ietf-bier-ipv6-requirements-09 Thread-Index: AQHWyKPhRHLDAc8CjUaOLwEQ20u7VQ== Date: Wed, 2 Dec 2020 14:10:17 +0000 Message-ID: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:959a:92d8:2b8e:d99a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a09c2103-314a-4635-13e5-08d896cbff0e x-ms-traffictypediagnostic: PH0PR11MB5175: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: A12AUQ8bRk1jn72MLYQb5ORPKOqmTLJJ0d42z3kzoPHDVlK+vtJoWKQRuD0E7C3rKUXfERXYTBvsrLu50GqNjlDekzFMjBRaY3RjZjKM/SGddT1iRQ56vGZhxV90NSOlDUi/jip92kRTfJC/v/ce1pchNz3DnOiENxlZaEE+j76E4p06KTswFRUXDvmsbnn0kb/1OvLUuf68sj2jyT+BQfOo20/7q8ZRzKp1QR6b9IpF1aE9rN8Vy77ntQ3fmVbkxqshhFmxkajLmQF/y9VpXixgXHqcYad1fdGUhaZVuf+OhMg46/CO+ZgB9kOP5xlOKufOck8ILO1yp6tzABULshM7RIpRTXWYNBQoet5eodOaF+/MUHVZJCRha2xlM8HK x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(376002)(136003)(346002)(39860400002)(316002)(83380400001)(36756003)(4326008)(6486002)(66574015)(33656002)(91956017)(66946007)(478600001)(66446008)(66476007)(66556008)(6512007)(64756008)(54906003)(8936002)(110136005)(8676002)(5660300002)(71200400001)(2906002)(86362001)(186003)(76116006)(2616005)(6506007)(53546011)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Umt5T0lKaWpha0hqVTIrZkVXeFRmQ3VuMVB6Zm5laitzYmJsNHlPWm0yd1RW?= =?utf-8?B?Mlh6eVVGZENQS3B1TXBFWlRtcXV5aFY4a0NaYUgwMEVTVWpSWEFjWTFYNGhD?= =?utf-8?B?b21MS1VJSXRNQzE1ZkJIdXVxWFVoMWlqb2h2cHNsSHlDZ2JIaWFTbXZKWnNM?= =?utf-8?B?T3YrT09HZVo0eHA0aU0wMmtyUzVDSDVQRlc0SkpzeUQ3RTZLZDlrY0FiR01j?= =?utf-8?B?RXZYcmxBdEFCcnNmZjlkYW5xNDR0RnIzZFpFSVBzeCtET0hpYThRcUVCVGp0?= =?utf-8?B?dnJGQXBNcXRLU3prRDFFM0VkQnhqTWozS0NTT0RDdVF3SFZrT25kUzVHVTAz?= =?utf-8?B?SjM2ZXhVc2ZITGlKdFVESWgydHB3dGdtMklLRDRFTTBXY1ZRdVdJVFpIOHps?= =?utf-8?B?OWZJWVlWZ2JPdTFLcjB6TXgzS25rTWRZVnZ1UzVMU0didk4rUWh6WE1MRmht?= =?utf-8?B?YjhNdjJldFNOWEFaTUVMR2V6NFc4UklmZVN6dDhBSzY3MWllVDFDOHBUd2tW?= =?utf-8?B?UmxneEsxc1YzKzBDVmRsNWFUOW01UnpFR2lOR2hMK0pMWEFXWW1WbmF4blF4?= =?utf-8?B?bGZ6NjZJdytIeXFQZDhWL0w1dzhHaE5VeG1sS1pIa3hBTlluTkIwYzRSY1ZY?= =?utf-8?B?ZFA4MGxzdjQySGNRVTRUMXVJbWRRdkdhcytmQnhQME9PeXJRckRUclR2TE1w?= =?utf-8?B?cHBPYnBvVEJTMHp5TUQ0cnhoRDJ4ci8vd1ZvWDNNUjk4NmNHSWN0ZDNUS1JK?= =?utf-8?B?czk3TzhVeUsybGloQ3BNblVxdjJKZWF1V1ZNVTRLenpUMG5tcm9HM1BqOHFT?= =?utf-8?B?M3N3WmxvY0FKWDFRbTFvMDQzL1hadUh5eTJyVVlQYzJZVzhNejQ3T3I4NlIy?= =?utf-8?B?QW94SUZZUDB2TGNobWRSdEVZZzBDbTNBYVdzcmM2aFNpTXRURlNnUDVGQzR2?= =?utf-8?B?STE5TFA2OUFVNnRGVXdBZUEyL1dXWHlHMWlJVnBJaUVJQWgyTk9jaEljYVg0?= =?utf-8?B?TFdrQzRyQmdKM2FTVnlHcWR2ZFZxQUZuNVFqY1B1NlVBaHpPbURIMk9rd1E0?= =?utf-8?B?NC90cXhDSTJabkErU2tRVEpKa1dqRitpandnelpQblNkd2N6bVYvdUlrTTAy?= =?utf-8?B?LytBdzhtZWdleE5zRVR2WUJ3Wk5mUGtUVGVLN0laMURQWXpLVHo4UlRjalQr?= =?utf-8?B?Q3hkaDBPczY0am5aSUs0ZkNHc1BvZ1NvbDlDQmxnY0NrdkhjRGR6OFY3KzZV?= =?utf-8?B?SUlOd1FXNE9oVWtLN2pKTHFIalNObG9SaXQ3d1FqSitHZjJ6TU9yS1pPSWFZ?= =?utf-8?B?VEtDL0V3aXVMSXp6cG03bVFIenJCNlAvZ3gvV3EvME9kTXhNQmZMM3l5VHZ6?= =?utf-8?B?WjdYY0toSXkrMUc3ODBCQWRmR1ZTcTVudis4bTd1UllRcGlEWUtFcVVoSGFK?= =?utf-8?Q?mqHZ6Pha?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a09c2103-314a-4635-13e5-08d896cbff0e X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2020 14:10:17.3748 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MGp3NQa+H98pXifjy3+jm43QTHsciiJmQR7V/6v7CMXjJwrF7d1GpiXEdnSLpAEr6YNqvhhaGJP/oXBNHP6gGg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5175 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 14:10:46 -0000 Wmhhb2h1aSAoSmVmZnJleSkgY29udGFjdGVkIG1lIGxhc3Qgd2VlayBhYm91dCB0aGUgR2VuZydz IHBvaW50ICMyIGFzIEkgd2FzIG9uZSBvZiB0aGUgcGVvcGxlIHJhaXNpbmcgdGhlIGNvbW1lbnQg ZHVyaW5nIElFVEYtMTA4IDZNQU4gc2Vzc2lvbiB3aGlsZSB3ZWFyaW5nICpubyBoYXQqLiBQbGVh c2UgYWxzbyBub3RlIHRoYXQgSSBhbSAqbm90KiBhIEJJRVIgZXhwZXJ0IGFuZCBub3QgYSBtZW1i ZXIgb2YgdGhlIEJJRVIgbGlzdC4NCg0KSGVyZSBpcyBteSByZXBseSB0byBaaGFvaHVpOg0KDQpF Vj4gRmlyc3QsIHBsZWFzZSBub3RlIHRoYXQgbXkgY29tbWVudCBhdCBJRVRGLTEwOCB3YXMgd2l0 aG91dCBhbnkgQUQgaGF0IGFuZCB0aGF0IEVyaWsgS2xpbmUgaXMgdGhlIHJlc3BvbnNpYmxlIEFE IGZvciA2TUFOLg0KDQpFVj4gVGhlbiwgcGxlYXNlIG5vdGUgdGhhdCB0aGUgY3VycmVudCBzdGF0 ZSBvZiBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIGlzIHRoYXQgbm8gbmV3IGV4dGVuc2lvbiBoZWFk ZXIgKEhFKSBtYXkgYmUgc3BlY2lmaWVkIA0KRVY+IGJ1dCB0aGUgZG9vciBpcyB3aWRlIG9wZW4g dG8gYWRkIG9wdGlvbnMgaW50byBleGlzdGluZyBFSCAgKGUuZy4sIGluIGhvcC1ieS1ob3Agb3B0 aW9ucyBvciBkZXN0aW5hdGlvbiBvcHRpb25zIGhlYWRlcnMpLg0KDQpFVj4gSEVzIGFyZSBmb2xs b3dlZCBieSBlaXRoZXIgYW5vdGhlciBFSCBvciBieSBhIHRyYW5zcG9ydCBsYXllciBoZWFkZXIg b3IgYnkgJ25vIG1vcmUgRUgnLiBXaGlsZSBhIHRyYW5zcG9ydCANCkVWPiBoZWFkZXIgaXMgZm9s bG93ZWQgYnkgYW4gJ2FwcGxpY2F0aW9uJyBwYXlsb2FkOiBUQ1AgcGF5bG9hZCwgSUNNUCBwYXls b2FkLCBHUkUvSVBpbklQIGVuY2Fwc3VsYXRlZCBwYWNrZXQgKHRoYXQgY291bGQgYmUgb2YgY291 cnNlICBhbHNvIEJJRVIgcGF5bG9hZCkuDQoNCkVWPiBJRiB0aGUgSVB2NiBwYWNrZXRzIGFyZSBz ZW50IHdpdGggYSBkZXN0aW5hdGlvbiBhZGRyZXNzIHRoYXQgaXMgTk9UIHRoZSBuZXh0IEJJRVIg cm91dGVyIEFORCANCkVWPiBJRiB0aGUgaW50ZXJtZWRpYXRlIHJvdXRlcnMgbXVzdCBwcm9jZXNz IHRoZSBCSUVSIGhlYWRlciwgdGhlbiBhIEJJRVIgb3B0aW9uIGluIHRoZSBIb3AtYnktSG9wIGV4 dGVuc2lvbiBoZWFkZXIgc291bmRzIG1vcmUgc3VpdGFibGUgdG8gbWUuDQoNCkVWPiBJZiB0aGUg SVB2NiBwYWNrZXRzIGFyZSBzZW50IHdpdGggYSBkZXN0aW5hdGlvbiBhZGRyZXNzIHRoYXQgaXMg dGhlIG5leHQgQklFUiByb3V0ZXIsIA0KRVY+IHRoZW4gdGhpcyBCSUVSIG92ZXIgSVB2NiBsb29r cyBtb3JlIGxpa2UgYSBHUkUvSVAtaW4tSVAgdG8gbWUsIHRoaXMgbWVhbnMgQklFUiBub3QgYXMg ZXh0ZW5zaW9uIGhlYWRlciANCkVWPiBidXQgbW9yZSBsaWtlIGEgJ3RyYW5zcG9ydCcgaGVhZGVy IChwcmV0dHkgbXVjaCBsaWtlIEdSRSBvciBJUC1pbi1JUCkuIEVsc2UsIGEgZGVzdGluYXRpb24g b3B0aW9uIGhlYWRlciBtYXkgYWxzbyBmaXQuDQoNCkVWPiBBZnRlciByZXZpZXdpbmcgdGhlIHNs aWRlcyB0aGF0IHlvdSBwcmVzZW50ZWQgYXQgSUVURi0xMDgsIHlvdSB3ZXJlIHJpZ2h0IGJ5IGFz a2luZyBmb3IgYSAncHJvdG9jb2wgbnVtYmVyJyBidXQsIHRvIGJlIHBlZGFudGljLCANCkVWPiB0 aGlzIGlzIG5vdCBhbiBleHRlbnNpb24gaGVhZGVyIGJ1dCByYXRoZXIgYSAndHJhbnNwb3J0JyBo ZWFkZXIuIEl0IHdpbGwgYWxzbyBoYXZlIHRoZSBhZGRlZCBiZW5lZml0IHRvIHdvcmsgd2l0aCB0 aGUgbGVnYWN5IElQdjQgcHJvdG9jb2wuIA0KRVY+IFRoZSBhbHRlcm5hdGl2ZSB3b3VsZCBiZSBh biBvcHRpb24gZm9yIHRoZSBkZXN0aW5hdGlvbiBvcHRpb25zIGhlYWRlci4gIFNvLCBiYXNlZCBv biB0aGUgQklFUiBXRy9hdXRob3JzJyBjaG9pY2UsIHRoZSByZWxldmFudCBXR3MgYXJlIA0KRVY+ IGVpdGhlciA2TUFOICh0byBhZGQgYSBkZXN0aW5hdGlvbi9IYkggb3B0aW9uKSBvciBJTlRBUkVB ICh0byByZXF1ZXN0IGEgcHJvdG9jb2wgbnVtYmVyKS4NCg0KVGhlIGxhc3Qgc2VudGVuY2UgYWJv dmUgaXMgd2l0aCBteSBJRVNHIGhhdCB0aG91Z2ggOy0pDQoNCkhvcGUgdGhpcyBjbGFyaWZpZXMN Cg0KLcOpcmljDQoNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206ICJHZW5n eHVlc29uZyAoR2VuZyBYdWVzb25nKSIgPGdlbmd4dWVzb25nQGh1YXdlaS5jb20+DQpEYXRlOiBT YXR1cmRheSwgMjggTm92ZW1iZXIgMjAyMCBhdCAwMzowNQ0KVG86ICJnanNoZXBAZ21haWwuY29t IiA8Z2pzaGVwQGdtYWlsLmNvbT4sICJKZWZmcmV5IChaaGFvaHVpKSBaaGFuZyIgPHp6aGFuZ0Bq dW5pcGVyLm5ldD4NCkNjOiBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPiwgQWx2 YXJvIFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4sIEJJRVIgV0cgPGJpZXJAaWV0Zi5v cmc+LCAiRVhULXpoYW5nLnpoZW5nQHp0ZS5jb20uY24iIDx6aGFuZy56aGVuZ0B6dGUuY29tLmNu PiwgVG9ueSBQcnp5Z2llbmRhIDx0b255c2lldGZAZ21haWwuY29tPiwgZHJhZnQtaWV0Zi1iaWVy LWlwdjYtcmVxdWlyZW1lbnRzIDxkcmFmdC1pZXRmLWJpZXItaXB2Ni1yZXF1aXJlbWVudHNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0JpZXJdIGRyYWZ0LWlldGYtYmllci1pcHY2LXJlcXVpcmVt ZW50cy0wOQ0KDQogICAgSGkgR3JlZywNCg0KICAgIEkgaGF2ZSBmb2xsb3dlZCB0aGUgdGhyZWFk LiBBbmQgSSBkb24ndCB0aGVyZSBpcyBjb25zZW5zdXMgYWJvdXQgQklFUiBJUHY2IHJlcXVpcmVt ZW50IGFuZCBCSUVSaW42IGluIFdHLiBIZXJlIGFyZSBzb21lIG15IGNvbmNlcm5zIHRoYXQgaGF2 ZSBiZWVuIGRpc2N1c3NlZCBpbiBJRVRGMTA5Og0KICAgIDEuIFdoeSB3ZSBuZWVkIGEgbmV3ICJu ZXh0IGhlYWRlciIgd2hlbiB0aGUgZXhpc3RpbmcgSVB2NiBleHRlbnNpb24gaGVhZGVyIGNvdWxk IHNhdGlzZnkgdGhlIEJJRVIgSVB2NiByZXF1aXJlbWVudDsNCiAgICAyLiBUaGUgY29tbWVudHMg cmFpc2VkIGJ5IDZNQU4gV0cgYW5kIElOVCBhcmVhIGFyZSBub3QgYWRkcmVzc2VkLCB3aGljaCBy ZXF1ZXN0cyB0aGUgZG9jdW1lbnQgdG8gYmUgZGlzY3Vzc2VkIGluIHRyYW5zcG9ydCBhcmVhOw0K ICAgIDMuIEJJRVJpbjYgaXMgbm90IGFuIGluZGVwZW5kZW50IHNvbHV0aW9uIHdoaWNoIHVzZXMg QklFUiBFdGhlcm5ldCB3aGVuIEJGUiBub2RlcyBhcmUgY29ubmVjdGVkIGRpcmVjdGx5Lg0KDQog ICAgQmVzdA0KICAgIFh1ZXNvbmcNCg0K From nobody Wed Dec 2 10:10:19 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5C63A1512 for ; Wed, 2 Dec 2020 10:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CYZ6hRiQ-C48 for ; Wed, 2 Dec 2020 10:10:13 -0800 (PST) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17D63A1426 for ; Wed, 2 Dec 2020 10:10:12 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id u2so1554444pls.10 for ; Wed, 02 Dec 2020 10:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=thLn2R9s+yeuimbXHmv5pLA5pqY5XawIlU1CqgGuopQ=; b=rsMnAn2c6cKRviaT8gfInuZdSYHwTk3NJTUfCtHAtB+6GXl9KPp6QWdDccjxCXK8JW UAWV9WO3rk/Xj9UbcPdXWgaIm7DU6ecnscgRzBLki9TuP4fylbCZR/6S9+YSkFGVcz2R 8hBbpipclwb1NGFOGnrXCCLTyPdlxRN25GVOhPi0D1nMoDPfyOUR+pkoq88h2YZUiPDv 2UXz2LdsugmHef9bxwTGWO/05pizmQczqwnzwgeLeIP+WB7sgoR9MWlqThFkY8ZiZR2s x6FesZvlG07MZPK2NpIHlBobiBDYpCJesGxh8yGeL74yxGZn6ab4BP8TZYx2a+YwIIU2 q+vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=thLn2R9s+yeuimbXHmv5pLA5pqY5XawIlU1CqgGuopQ=; b=cuNrJxmNOaBhIxi5817am02Vl1xXSNkKgEwDu3nP+vDAvjFEm6YI8JDTM5DttVkVRe 6zVXqjnTmG1WAEQDZb2yjomBk3mDtk3w6kIkgUv3f9xRmMkFWcwho9uCI0fRo25Cn5ev gJcd8u1wDk+6pogvI9G9UZbmINIWyLrt8zAWHjfMQ9IKT2K6KQVXXb+hIa83hPAjdmQO 8HA4zzNx/sFxQgGtS05vaSxV91dfhdGiMC6OgUY6yhtfIAxRYwk13zPG7eH5DunmzM2B KisQGeegQttpHaiHgQIf1kTtMV0pGy0fQmbqd888PlA9OjU9ac6DAQ7anrL7wWYfZv0L w8AA== X-Gm-Message-State: AOAM5306xDGroU/0L87eZ5S4UPndZMeuAFIgpYPqmDoFm1O0NubZ5/9k oAk2Uuj5oE78ahxhdjeh8AL2fdRxPGtHz5fg6Po= X-Google-Smtp-Source: ABdhPJxsd4F9gQaTdXFonyyeOSAojPSyQeRH8zGGsxAzGDnXbRT9+bA8QPH5zr75HrY0gpY/W9LIe4miKOXx66IvRtI= X-Received: by 2002:a17:90a:178b:: with SMTP id q11mr1022799pja.132.1606932612102; Wed, 02 Dec 2020 10:10:12 -0800 (PST) MIME-Version: 1.0 References: <00b201d6c70b$0618bae0$124a30a0$@olddog.co.uk> In-Reply-To: From: Gyan Mishra Date: Wed, 2 Dec 2020 13:10:01 -0500 Message-ID: To: Greg Mirsky , Greg Shepherd , Michael McBride , Tony Przygienda Cc: BIER WG , "Jeffrey (Zhaohui) Zhang" , "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary="00000000000085c00c05b57f279b" Archived-At: Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 18:10:16 -0000 --00000000000085c00c05b57f279b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 ..from Adrian & Mike So how about this? - BIER has a history of starting with Experimental work and seeing how it develops - This deployment case is somewhat niche: multicast is a bit rare, BIER is not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, bridging over IPv6 is a subset of BIER. - Why not adopt both approaches as Experimental and set some clear terms for the experiment? On Mon, Nov 30, 2020 at 2:05 PM Michael McBride < michael.mcbride@futurewei.com> wrote: > - Why not adopt both approaches as Experimental and set some clear terms > for the experiment? > > This! > > mike > > -----Original Message----- > From: BIER On Behalf Of Adrian Farrel > Sent: Monday, November 30, 2020 3:22 AM > To: 'Jeffrey (Zhaohui) Zhang' > Cc: 'BIER WG' > Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 > > Hey Jeffrey, > > It may be because I'm late to the discussion, but when you say... > > > With the above, there is simply no need for another solution in my view= . > > ...this seems to suggest that there is already a solution. > AFAICS, while you might support only one of the two solutions, there are > two solutions. Neither has been adopted and neither has been "selected". > > You might have better phrased this as "this is simply no need for two > solutions." It might be true that most people agree with that, but since > they will only agree if their preferred solution is chosen, it is possibl= y > not very helpful. > > However, you go on... > > > Of course the WG can continue discussing BIERv6 and may determine that > > it is nice to have BIERv6 as well, but we should not bundle them > > together when it comes to adoption. > > ...which seems to suggest that you don't think it is harmful to discuss > two solutions. > Since the adoption of one on its own is likely to reduce the chances of > adoption of the other, not bundling the adoptions might be a little > simplistic. I am not proposing that we poll the adoption of either soluti= on > first. Nor am I suggesting making it an either/or adoption poll. > > So how about this? > > - BIER has a history of starting with Experimental work and seeing how it > develops > - This deployment case is somewhat niche: multicast is a bit rare, BIER i= s > not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, > bridging over IPv6 is a subset of BIER. > - Why not adopt both approaches as Experimental and set some clear terms > for the experiment? > > Cheers, > Adrian > > -----Original Message----- > From: BIER On Behalf Of Jeffrey (Zhaohui) Zhang > Sent: 28 November 2020 21:54 > To: Michael McBride ; gjshep@gmail.com > Cc: BIER WG ; Gyan Mishra ; > draft-ietf-bier-ipv6-requirements < > draft-ietf-bier-ipv6-requirements@ietf.org>; EXT-zhang.zheng@zte.com.cn < > zhang.zheng@zte.com.cn>; Alvaro Retana > Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 > > To clarify, there is no gap in the BIERin6 solution (besides the new "nex= t > header" code point). It's just that some text are needed to explain how t= he > requirements are met with the BIERin6 solution - whether it is a > requirement already listed in the current requirements draft, or have bee= n > brought up in recent mailing list discussions (I know of two in recent > discussions). > > BIERin6 is based on RFC 8296 (plus the new "next header" code point for > IPv6 encapsulation), and is a generic solution with the following > properties: > > 1. clean layering - BIER over L2/tunnel and it can carry different payloa= d > types including SRv6 2. IPv4/IPv6 independent (of course you need differe= nt > signaling) 3. L2 independent - as long as the L2 header can indicate with= a > code point that a BIER header follows 4. tunnel type independent - as lon= g > as the tunnel header can indicate with a code point that a BIER header > follows 5. can work one-hop or multi-hop tunnels nicely 6. can work with > SRv6 based services nicely > > With the above, there is simply no need for another solution in my view. > Of course the WG can continue discussing BIERv6 and may determine that it > is nice to have BIERv6 as well, but we should not bundle them together wh= en > it comes to adoption. That's why I suggested in the last BIER session the > following: > > - Adopt BIERin6 > - Discuss BIERv6 further > > Jeffrey > > -----Original Message----- > From: Michael McBride > Sent: Saturday, November 28, 2020 2:15 PM > To: gjshep@gmail.com; Jeffrey (Zhaohui) Zhang > Cc: Gyan Mishra ; Alvaro Retana < > aretana.ietf@gmail.com>; BIER WG ; > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < > draft-ietf-bier-ipv6-requirements@ietf.org> > Subject: RE: draft-ietf-bier-ipv6-requirements-09 > > [External Email. Be cautious of content] > > > Hi Greg, > > >Thank you Jeffrey and Gyan for sticking with the thread of the > conversation to advance the discussion. It's clear now that all of the > requirements >discussed so far can be addressed by the BIERin6 draft if w= e > flesh out the discussed gaps. > > >I would like to see Jeffrey and Gyan take over as primary authors of > >BIERin6 to include the gaps discussed here so that it fully encompases > the requirements so far described, for WG adoption. > > I'm sure I'm misinterpreting. What it sounds like you are saying is "I > want bierin6 to be adopted so let's fix the gaps so we can begin". Since > both solutions meet the requirements, I'm hoping you meant "Let's fix the > gaps in bierin6 so we can begin adoption calls for both bierv6 and bierin= 6". > > mike > > > On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang < > zzhang@juniper.net> > wrote: > > > Hi Gyan, > > > > > > > > Great that we reached consensus on BIERin6. > > > > Now there are two lingering points alluded to in this thread, but > > given it=E2=80=99s been such a long and deeply nested tread, I=E2=80=99= ll start a new > > thread about it. > > > > > > > > Thanks. > > > > Jeffrey > > > > > > > > *From:* Gyan Mishra > > *Sent:* Monday, November 23, 2020 1:32 AM > > *To:* Jeffrey (Zhaohui) Zhang > > *Cc:* Alvaro Retana ; BIER WG ; > > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < > > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < > > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com > > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 > > > > > > > > *[External Email. Be cautious of content]* > > > > > > > > Hi Jeffrey > > > > > > > > That=E2=80=99s the last of my questions related to BIERin6. > > > > > > > > I thank you for taking the time to go over the BIERin6 draft in detail. > > > > > > > > We have reached consensus as well as are in sync, and I now have a > > better understanding of BIERin6. > > > > > > > > During the discussions I did mention that maybe in BIERin6 optional > > IPv6 tunneling should be removed, as it seemed to create some > > confusion, but now I am clear and as both the L2/tunnel and IPv6 > > L3/tunnel encapsulation single hop or multi hop tunnel both have the > > clean BIER layering and complement each other I agree they belong > together in the same draft. > > > > Even though L2/tunnel exists today as part of RFC8296 it makes sense > > to be part of the overall BIERin6 solution. > > > > > > > > I am clear on the two IANA code points requests required for the > > optional > > IPV6 encapsulation option. > > > > > > > > Over the course of this thread we did touch on some technical reasons > > why > > IPV6 encapsulation is necessary which I you mentioned in some of your > > responses. > > > > > > > > Overall throughout the discussions I agree that BIERin6 IPV6 tunnel > > option and BIERv6 are not transitional and are long term solutions and > > there are reasons why that we can add to the requirements draft as to > > why IPV6 encapsulation is necessary below: > > > > > > > > - Operator requirement for IPV6 encapsulated packets and not L2 > > encapsulation. > > > > -FRR > > > > > > > > I think we are all set to start updating the Requirements draft. > > > > > > > > In-line Gyan6> > > > > > > > > Kind Regards > > > > > > > > Gyan > > > > > > > > On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang < > > zzhang@juniper.net> wrote: > > > > Gyan, > > > > > > > > Please see zzh6> below. > > > > > > > > *From:* Gyan Mishra > > *Sent:* Sunday, November 22, 2020 9:49 PM > > *To:* Jeffrey (Zhaohui) Zhang > > *Cc:* Alvaro Retana ; BIER WG ; > > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < > > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < > > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com > > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 > > > > > > > > *[External Email. Be cautious of content]* > > > > > > > > > > > > Hi Jeffrey > > > > > > > > Agreed we have reached a consensus. > > > > > > > > > > > > Few more questions to iron out understanding. > > > > > > > > In line gyan4> > > > > > > > > Zzh6> Apparently there are still disconnects =F0=9F=98=8A > > > > Gyan> Thank you for all the detailed responses. We are in sync now! > > > > On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang < > > zzhang@juniper.net> wrote: > > > > Hi Gyan, > > > > > > > > Yes I believe we=E2=80=99ve reached consensus. > > > > > > > > Please see zzh5> below about some details. > > > > > > > > *From:* Gyan Mishra > > *Sent:* Sunday, November 22, 2020 4:19 PM > > *To:* Jeffrey (Zhaohui) Zhang > > *Cc:* Alvaro Retana ; BIER WG ; > > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < > > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < > > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com > > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 > > > > > > > > *[External Email. Be cautious of content]* > > > > > > > > Hi Jeffrey > > > > > > > > This has been a very informative exchange and extremely helpful for > > all of us to get onto the same page from a basic understanding POV. > > > > > > > > Much appreciated all your help and feedback helping clarify my confusio= n. > > > > > > > > I am answering in-line but now connecting the dots how is in today=E2= =80=99s > > RFC > > 8296 Non MPLS BIER Ethernet going to transport IPv6? > > > > > > > > From your answers below it cannot work as we need two IANA code point > > one for IPv6 next header type and ICMPv6. > > > > > > > > Zzh5> The existing model/concept works except that we need to two code > > points if IPv6 tunneling is used for either getting over non-BFRs or > > for FRR. One may deem non-BFR as a short-term scenario but FRR will be > > here for the long run. > > > > > > > > Gyan4>I am a little confused here with the code points. For > > BIERin6 =E2=80=9CL2=E2=80=9D BIER scenario RFC 8296 Non MPLS BIER Ether= net Ether type > 0xAB37. > > > > > > > > Ethernet -0xAB37 l BIER | IPv6 | payload > > > > > > > > Zzh6> Note that IPv6 header is not needed =E2=80=93 it should be Ethern= et > > Zzh6> -0xAB37 > > l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6 > > header may be inserted between BIER and payload, only for the SRv6 > > style VPN purpose. > > > > Gyan> Understood > > > > Ethernet -0xAB37 l BIER l ICMPv6 | payload > > > > > > > > Zzh6> ICMP was mentioned not for encapsulation but for the following: > > > > Gyan6>Understood > > > > Zzh6> 2.1. IPv6 Options Considerations > > > > > > > > For directly connected BIER routers, IPv6 Hop-by-Hop or Destination > > > > options are irrelevant and SHOULD NOT be inserted by BFIR on the > > > > BIERin6 packet. In this case IPv6 header, Next Header field should > > > > be set to TBD. Any IPv6 packet arriving on BFRs and BFERs, with > > > > multiple extension header where the last extension header has a > > Next > > > > Header field set to TBD, SHOULD be discard and the node should > > > > transmit an ICMP Parameter Problem message to the source of the > > > > packet (BFIR) with an ICMP code value of TBD10 ('invalid options > > for > > > > BIERin6'). > > > > > > > > In this particular scenario where adjacent BFRs support Ethernet link > > layer in an IPV6 environment and IPv6 or ICMPv6 encapsulation and the > > need for the next header code point above is the packet format: > > > > > > > > Excerpt from RFC 8296 > > > > > > > > Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet > > > > header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332 > > > defense.com%2Fv3%2F__https%3A%2F%2Fnam11.safelinks.protection.outloo&a > > mp;data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7Cb501cd53f4bd4d3f2= c > > c208d89522310a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6374233214 > > 00994370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DZTD3UoFNPPbw5cq63CD77b= J > > 6NP3gwiaciyErJ1OMMFI%3D&reserved=3D0 > > k.com/?url=3Dhttps*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cet= p > > u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$ > > defense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!! > > NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8 > > 4ssHlj%24&data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7C97b8a3= 4 > > 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7 > > C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D8EiHsMns5Ju= t > > 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&reserved=3D0>]. IEEE > > > > has assigned Ethertype 0xAB37 for non-MPLS BIER packets. > > > > > > > > > > > > In the case of BIERin6 optional encapsulation option, in case where > > operators requires packets forwarded in IPv6 or tunneling over Non BFR > > packet format below: > > > > > > > > IPv6 outer header l BIER l Data > > > > > > > > So here the next header is BIER so corresponding next header code point= . > > > > > > > > > > > > So below is for both cases IANA code point allocation for =E2=80=9CL2= =E2=80=9D next > > header where next header is IPv6 or ICMPV6, and then the optional IPv6 > > encapsulation option where the next header is BIER. > > > > > > > > Would those be two separate IANA code point requests I what I see from > > the packet format. > > > > > > > > IANA L2 scenario: > > > > 2 code point requests for L2 for next header IPv6 and ICMP > > > > > > > > Zzh6> I don=E2=80=99t follow what you=E2=80=99re talking about. If BIER= header follows > > Zzh6> L2 > > header directly, no new code point is needed. It=E2=80=99s just =E2=80= =9CEthernet > > 0xAB37 | BIER | payload=E2=80=9D. > > > > > > > > Gyan6> Agreed. > > > > > > > > IANA optional IPv6 scenario: > > > > 1 code point request for IPv6 for next header BIER > > > > > > > > Zzh6> If IPv6 encapsulation is used, either on between directly > > Zzh6> connected > > BFRs or indirectly connected BFRs, a new =E2=80=9Cnext header=E2=80=9D = code point is > > needed for BIER. > > > > Gyan6>Understood > > > > > > 5 > > < > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Furlde= fense.com%2Fv3%2F__https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%= 3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fh= tml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnh= YihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24%26amp%3Bdata%3D04*= 7C01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7= C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0= *3D*7C1000%26amp%3Bsdata%3DnEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D%2= 6amp%3Breserved%3D0__%3BJSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Xqc= OU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N%24&data= =3D04%7C01%7Cmichael.mcbride%40futurewei.com%7Cb501cd53f4bd4d3f2cc208d89522= 310a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637423321400994370%7CUnkn= own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV= CI6Mn0%3D%7C1000&sdata=3DfszY8MUPUn7HymiDWii297tMT7ztwl1VwUcn25Rlo58%3D= &reserved=3D0 > >. > > IANA Considerations > > > > > > > > > > > > IANA is requested to assign a new "BIER" type for "Next Header" in > > > > the "Assigned Internet Protocol Numbers" registry. > > > > > > > > IANA is requested to assign a new "BIERin6" type for "invalid > > > > options" in the "ICMP code value" registry. > > > > > > > > IANA is requested to assign a new "BIER IPv6 transportation > > Sub-sub- > > > > TLV" type in the "OSPFv3 BIER Ethernet Encapsulation sub-TLV" > > > > Registry. > > > > > > > > IANA is requested to set up a new "BIER IPv6 transportation > > Sub-sub- > > > > sub-TLV" type in the "IS-IS BIER Ethernet Encapsulation sub-sub-TLV" > > > > Registry. > > > > > > > > > > > > My point is that the IANA allocation is different as the next header > > is different for the L2 scenario where next header is IPv6 or ICMPV6, > > and IPv6 encapsulation scenario where the next header is BIER. > > > > > > > > Zzh6> If BIER header follows L2 header directly, BIER Ethertype is > > Zzh6> used > > (assuming Ethernet is the L2). > > > > Gyan>Understood > > > > Based on this point I am making could we just do a RFC8296 bis version > > and add the IANA code points for IPv6 and ICMPv6. > > > > > > > > Zzh6> Given the confusion/contention that have happened in the last > > Zzh6> two > > years, it is much better to specifically have a spec dedicated to > > supporting BIER in IPv6. > > > > Gyan6> I think now looking at it holistically speaking I can now see > > parity between the L2/tunnel and L3/tunnel both also having the clean > > layering. So I can see why adding existing L2/tunnel to BIERin6 even > > though it already exists made sense to bundle into BIERin6 total > > solution > > Juniper Business Use Only > _______________________________________________ > BIER mailing list > BIER@ietf.org > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fbier&data=3D04%7C01%7Cmichael.mcbride%40= futurewei.com%7Cb501cd53f4bd4d3f2cc208d89522310a%7C0fee8ff2a3b240189c753a1d= 5591fedc%7C1%7C0%7C637423321401004365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL= jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3Dz%= 2FZLlPIEI9raumWwe9iKpI7wLJcoedPNZUKPepNLuR0%3D&reserved=3D0 > > _______________________________________________ > BIER mailing list > BIER@ietf.org > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fbier&data=3D04%7C01%7Cmichael.mcbride%40= futurewei.com%7Cb501cd53f4bd4d3f2cc208d89522310a%7C0fee8ff2a3b240189c753a1d= 5591fedc%7C1%7C0%7C637423321401004365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL= jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3Dz%= 2FZLlPIEI9raumWwe9iKpI7wLJcoedPNZUKPepNLuR0%3D&reserved=3D0 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000085c00c05b57f279b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

+1=C2=A0

=
..from Adrian & Mike

So = how about this?
- BIER has a history of starting with Experiment= al work and seeing how it develops
- Thi= s deployment case is somewhat niche: multicast is a bit rare, BIER is not w= idely deployed for multicast, IPv6 is still (sadly) not ubiquitous, bridgin= g over IPv6 is a subset of BIER.
- Why n= ot adopt both approaches as Experimental and set some clear terms for the e= xperiment?
<= div dir=3D"auto">

On Mon, Nov 30, 2020 at 2:05 PM Michael McBride &= lt;michael.mcbride@futurew= ei.com> wrote:
- Why not ado= pt both approaches as Experimental and set some clear terms for the experim= ent?

This!

mike

-----Original Message-----
From: BIER <b= ier-bounces@ietf.org> On Behalf Of Adrian Farrel
Sent: Monday, November 30, 2020 3:22 AM
To: 'Jeffrey (Zhaohui) Zhang' <zzhang=3D40juniper.net@dmarc.ietf.org&= gt;
Cc: 'BIER WG' <bier@ietf.org>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

Hey Jeffrey,

It may be because I'm late to the discussion, but when you say...

> With the above, there is simply no need for another solution in my vie= w.

...this seems to suggest that there is already a solution.
AFAICS, while you might support only one of the two solutions, there are tw= o solutions. Neither has been adopted and neither has been "selected&q= uot;.

You might have better phrased this as "this is simply no need for two = solutions." It might be true that most people agree with that, but sin= ce they will only agree if their preferred solution is chosen, it is possib= ly not very helpful.

However, you go on...

> Of course the WG can continue discussing BIERv6 and may determine that=
> it is nice to have BIERv6 as well, but we should not bundle them
> together when it comes to adoption.

...which seems to suggest that you don't think it is harmful to discuss= two solutions.
Since the adoption of one on its own is likely to reduce the chances of ado= ption of the other, not bundling the adoptions might be a little simplistic= . I am not proposing that we poll the adoption of either solution first. No= r am I suggesting making it an either/or adoption poll.

So how about this?

- BIER has a history of starting with Experimental work and seeing how it d= evelops
- This deployment case is somewhat niche: multicast is a bit rare, BIER is = not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, br= idging over IPv6 is a subset of BIER.
- Why not adopt both approaches as Experimental and set some clear terms fo= r the experiment?

Cheers,
Adrian

-----Original Message-----
From: BIER <b= ier-bounces@ietf.org> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 28 November 2020 21:54
To: Michael McBride <michael.mcbride@futurewei.com>; gjshep@gmail.com
Cc: BIER WG <bier@iet= f.org>; Gyan Mishra <hayabusagsm@gmail.com>; draft-ietf-bier-ipv6-requirem= ents <draft-ietf-bier-ipv6-requirements@ietf.org>; EXT-zhang.zheng@zt= e.com.cn <zhang.zheng@zte.com.cn>; Alvaro Retana <aretana.ietf@gmail.com>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

To clarify, there is no gap in the BIERin6 solution (besides the new "= next header" code point). It's just that some text are needed to e= xplain how the requirements are met with the BIERin6 solution - whether it = is a requirement already listed in the current requirements draft, or have = been brought up in recent mailing list discussions (I know of two in recent= discussions).

BIERin6 is based on RFC 8296 (plus the new "next header" code poi= nt for IPv6 encapsulation), and is a generic solution with the following pr= operties:

1. clean layering - BIER over L2/tunnel and it can carry different payload = types including SRv6 2. IPv4/IPv6 independent (of course you need different= signaling) 3. L2 independent - as long as the L2 header can indicate with = a code point that a BIER header follows 4. tunnel type independent - as lon= g as the tunnel header can indicate with a code point that a BIER header fo= llows 5. can work one-hop or multi-hop tunnels nicely 6. can work with SRv6= based services nicely

With the above, there is simply no need for another solution in my view. Of= course the WG can continue discussing BIERv6 and may determine that it is = nice to have BIERv6 as well, but we should not bundle them together when it= comes to adoption. That's why I suggested in the last BIER session the= following:

- Adopt BIERin6
- Discuss BIERv6 further

Jeffrey

-----Original Message-----
From: Michael McBride <michael.mcbride@futurewei.com>
Sent: Saturday, November 28, 2020 2:15 PM
To: gjshep@gmail.com<= /a>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Alvaro Retana <aretana.ietf@gmail.com>; BIER = WG <bier@ietf.org= >; EXT-z= hang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <tonysietf@gmail.com&g= t;; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-require= ments@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]


Hi Greg,

>Thank you Jeffrey and Gyan for sticking with the thread of the conversa= tion to advance the discussion. It's clear now that all of the requirem= ents >discussed so far can be addressed by the BIERin6 draft if we flesh= out the discussed gaps.

>I would like to see Jeffrey and Gyan take over as primary authors of >BIERin6 to include the gaps discussed here so that it fully encompases = the requirements so far described, for WG adoption.

I'm sure I'm misinterpreting. What it sounds like you are saying is= "I want bierin6 to be adopted so let's fix the gaps so we can beg= in". Since both solutions meet the requirements, I'm hoping you me= ant "Let's fix the gaps in bierin6 so we can begin adoption calls = for both bierv6 and bierin6".

mike


On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Hi Gyan,
>
>
>
> Great that we reached consensus on BIERin6.
>
> Now there are two lingering points alluded to in this thread, but
> given it=E2=80=99s been such a long and deeply nested tread, I=E2=80= =99ll start a new
> thread about it.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Monday, November 23, 2020 1:32 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> That=E2=80=99s the last of my questions related to BIERin6.
>
>
>
> I thank you for taking the time to go over the BIERin6 draft in detail= .
>
>
>
> We have reached consensus as well as are in sync,=C2=A0 and I now have= a
> better understanding of BIERin6.
>
>
>
> During the discussions I did mention that maybe in BIERin6 optional > IPv6 tunneling should be removed, as it seemed to create some
> confusion, but now I am clear and as both the L2/tunnel and IPv6
> L3/tunnel encapsulation single hop or multi hop tunnel both have the <= br> > clean BIER layering and complement each other I agree they belong toge= ther in the same draft.
>
> Even though L2/tunnel exists today as part of RFC8296 it makes sense <= br> > to be part of the overall BIERin6 solution.
>
>
>
> I am clear on the two IANA code points requests required for the
> optional
> IPV6 encapsulation option.
>
>
>
> Over the course of this thread we did touch on some technical reasons =
> why
> IPV6 encapsulation is necessary which I you mentioned in some of your =
> responses.
>
>
>
> Overall throughout the discussions I agree that BIERin6 IPV6 tunnel > option and BIERv6 are not transitional and are long term solutions and=
> there are reasons why that we can add to the requirements draft as to =
> why IPV6 encapsulation is necessary below:
>
>
>
> - Operator requirement for IPV6 encapsulated packets=C2=A0 and not L2 =
> encapsulation.
>
> -FRR
>
>
>
> I think we are all set to start updating the Requirements draft.
>
>
>
> In-line Gyan6>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper= .net> wrote:
>
> Gyan,
>
>
>
> Please see zzh6> below.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 9:49 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Agreed we have reached a consensus.
>
>
>
>
>
> Few more questions to iron out understanding.
>
>
>
> In line gyan4>
>
>
>
> Zzh6> Apparently there are still disconnects =F0=9F=98=8A
>
>=C2=A0 Gyan> Thank you for all the detailed responses.=C2=A0 We are = in sync now!
>
> On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper= .net> wrote:
>
> Hi Gyan,
>
>
>
> Yes I believe we=E2=80=99ve reached consensus.
>
>
>
> Please see zzh5> below about some details.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 4:19 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> This has been a very informative exchange and extremely helpful for > all of us to get onto the same page from a basic understanding POV. >
>
>
> Much appreciated all your help and feedback helping clarify my confusi= on.
>
>
>
> I am answering in-line but now connecting the dots how is in today=E2= =80=99s
> RFC
> 8296 Non MPLS BIER Ethernet going to transport IPv6?
>
>
>
> From your answers below it cannot work as we need two IANA code point =
> one for IPv6 next header type and ICMPv6.
>
>
>
> Zzh5> The existing model/concept works except that we need to two c= ode
> points if IPv6 tunneling is used for either getting over non-BFRs or <= br> > for FRR. One may deem non-BFR as a short-term scenario but FRR will be=
> here for the long run.
>
>
>
>=C2=A0 =C2=A0 =C2=A0Gyan4>I am a little confused here with the code = points.=C2=A0 For
> BIERin6 =E2=80=9CL2=E2=80=9D BIER scenario RFC 8296 Non MPLS BIER Ethe= rnet Ether type 0xAB37.
>
>
>
> Ethernet -0xAB37 l BIER | IPv6 | payload
>
>
>
> Zzh6> Note that IPv6 header is not needed =E2=80=93 it should be Et= hernet
> Zzh6> -0xAB37
> l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6=
> header may be inserted between BIER and payload, only for the SRv6 > style VPN purpose.
>
> Gyan> Understood
>
> Ethernet -0xAB37 l BIER l ICMPv6 | payload
>
>
>
> Zzh6> ICMP was mentioned not for encapsulation but for the followin= g:
>
>=C2=A0 Gyan6>Understood
>
> Zzh6> 2.1.=C2=A0 IPv6 Options Considerations
>
>
>
>=C2=A0 =C2=A0 For directly connected BIER routers, IPv6 Hop-by-Hop or D= estination
>
>=C2=A0 =C2=A0 options are irrelevant and SHOULD NOT be inserted by BFIR= on the
>
>=C2=A0 =C2=A0 BIERin6 packet.=C2=A0 In this case IPv6 header, Next Head= er field should
>
>=C2=A0 =C2=A0 be set to TBD.=C2=A0 Any IPv6 packet arriving on BFRs and= BFERs, with
>
>=C2=A0 =C2=A0 multiple extension header where the last extension header= has a
> Next
>
>=C2=A0 =C2=A0 Header field set to TBD, SHOULD be discard and the node s= hould
>
>=C2=A0 =C2=A0 transmit an ICMP Parameter Problem message to the source = of the
>
>=C2=A0 =C2=A0 packet (BFIR) with an ICMP code value of TBD10 ('inva= lid options
> for
>
>=C2=A0 =C2=A0 BIERin6').
>
>
>
> In this particular scenario where adjacent BFRs support Ethernet link =
> layer in an IPV6 environment and=C2=A0 IPv6 or ICMPv6 encapsulation an= d the
> need for the next header code point above is the packet format:
>
>
>
> Excerpt from RFC 8296
>
>
>
>=C2=A0 =C2=A0 Therefore, if a non-MPLS BIER packet is encapsulated in a= n Ethernet
>
>=C2=A0 =C2=A0 header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC53= 32
> <https://nam11.safeli= nks.protection.outlook.com/?url=3Dhttps%3A%2F%2Furl
> de= fense.com%2Fv3%2F__https%3A%2F%2Fnam11.safelinks.protection.outloo&= a
> mp;data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7Cb501cd53f4bd4d3= f2c
> c208d89522310a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6374233214=
> 00994370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL=
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DZTD3UoFNPPbw5cq63= CD77bJ
> 6NP3gwiaciyErJ1OMMFI%3D&amp;reserved=3D0
> k.com/?url=3Dhtt= ps*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp
> u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$
> de= fense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!!<= br> > NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8=
> 4ssHlj%24&amp;data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7C= 97b8a34
> 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7=
> C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj=
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D8EiHsM= ns5Jut
> 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&amp;reserved=3D0>].=C2=A0 IE= EE
>
>=C2=A0 =C2=A0 has assigned Ethertype 0xAB37 for non-MPLS BIER packets.<= br> >
>
>
>
>
> In the case of BIERin6 optional encapsulation option, in case where > operators requires packets forwarded in IPv6 or tunneling over Non BFR=
> packet format below:
>
>
>
> IPv6 outer header l BIER l Data
>
>
>
> So here the next header is BIER so corresponding next header code poin= t.
>
>
>
>
>
> So below is for both cases IANA code point allocation for =E2=80=9CL2= =E2=80=9D next
> header where next header is IPv6 or ICMPV6, and then the optional IPv6=
> encapsulation option where the next header is BIER.
>
>
>
> Would those be two separate IANA code point requests I what I see from=
> the packet format.
>
>
>
> IANA L2 scenario:
>
> 2 code point requests for L2 for next header IPv6 and ICMP
>
>
>
> Zzh6> I don=E2=80=99t follow what you=E2=80=99re talking about. If = BIER header follows
> Zzh6> L2
> header directly, no new code point is needed. It=E2=80=99s just =E2=80= =9CEthernet
> 0xAB37 | BIER | payload=E2=80=9D.
>
>
>
>=C2=A0 =C2=A0 =C2=A0Gyan6> Agreed.
>
>
>
> IANA optional IPv6 scenario:
>
> 1 code point request for IPv6 for next header BIER
>
>
>
> Zzh6> If IPv6 encapsulation is used, either on between directly > Zzh6> connected
> BFRs or indirectly connected BFRs, a new =E2=80=9Cnext header=E2=80=9D= code point is
> needed for BIER.
>
>=C2=A0 Gyan6>Understood
>
>
> 5
> <https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam11.safelinks.protection.outlook.= com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.= org*2Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj= _z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24%26amp%3Bdat= a%3D04*7C01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e= 35223*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnk= nown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0*3D*7C1000%26amp%3Bsdata%3DnEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25k= j0*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO= -gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N%24&= ;amp;data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7Cb501cd53f4bd4d3f2cc= 208d89522310a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6374233214009943= 70%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h= aWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DfszY8MUPUn7HymiDWii297tMT7ztwl1Vw= Ucn25Rlo58%3D&amp;reserved=3D0 >.
> IANA Considerations
>
>
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIER" type f= or "Next Header" in
>
>=C2=A0 =C2=A0 the "Assigned Internet Protocol Numbers" regist= ry.
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIERin6" typ= e for "invalid
>
>=C2=A0 =C2=A0 options" in the "ICMP code value" registry= .
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIER IPv6 transpo= rtation
> Sub-sub-
>
>=C2=A0 =C2=A0 TLV" type in the "OSPFv3 BIER Ethernet Encapsul= ation sub-TLV"
>
>=C2=A0 =C2=A0 Registry.
>
>
>
>=C2=A0 =C2=A0 IANA is requested to set up a new "BIER IPv6 transpo= rtation
> Sub-sub-
>
>=C2=A0 =C2=A0 sub-TLV" type in the "IS-IS BIER Ethernet Encap= sulation sub-sub-TLV"
>
>=C2=A0 =C2=A0 Registry.
>
>
>
>
>
> My point is that the IANA allocation is different as the next header <= br> > is different for the L2 scenario where next header is IPv6 or ICMPV6, =
> and IPv6 encapsulation scenario where the next header is BIER.
>
>
>
> Zzh6> If BIER header follows L2 header directly, BIER Ethertype is =
> Zzh6> used
> (assuming Ethernet is the L2).
>
>=C2=A0 Gyan>Understood
>
> Based on this point I am making could we just do a RFC8296 bis version=
> and add the IANA code points for IPv6 and ICMPv6.
>
>
>
> Zzh6> Given the confusion/contention that have happened in the last=
> Zzh6> two
> years, it is much better to specifically have a spec dedicated to
> supporting BIER in IPv6.
>
>=C2=A0 Gyan6> I think now looking at it holistically speaking I can = now see
> parity between the L2/tunnel and L3/tunnel both also having the clean =
> layering.=C2=A0 So I can see why adding existing L2/tunnel to BIERin6 = even
> though it already exists made sense to bundle into BIERin6 total
> solution

Juniper Business Use Only
_______________________________________________
BIER mailing list
BIER@ietf.org
https://nam11.safelinks.pro= tection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%= 2Fbier&amp;data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7Cb501cd53f= 4bd4d3f2cc208d89522310a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637423= 321401004365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3Dz%2FZLlPIEI9raumWwe9iKp= I7wLJcoedPNZUKPepNLuR0%3D&amp;reserved=3D0

_______________________________________________
BIER mailing list
BIER@ietf.org
https://nam11.safelinks.pro= tection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%= 2Fbier&amp;data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7Cb501cd53f= 4bd4d3f2cc208d89522310a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637423= 321401004365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3Dz%2FZLlPIEI9raumWwe9iKp= I7wLJcoedPNZUKPepNLuR0%3D&amp;reserved=3D0
_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier
--
--00000000000085c00c05b57f279b-- From nobody Wed Dec 2 12:53:44 2020 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A394C3A1491; Wed, 2 Dec 2020 12:53:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bier@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: bier@ietf.org Message-ID: <160694241959.13930.9259285848061737239@ietfa.amsl.com> Date: Wed, 02 Dec 2020 12:53:39 -0800 Archived-At: Subject: [Bier] I-D Action: draft-ietf-bier-pmmm-oam-09.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 20:53:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF. Title : Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer Authors : Greg Mirsky Lianshu Zheng Mach Chen Giuseppe Fioccola Filename : draft-ietf-bier-pmmm-oam-09.txt Pages : 9 Date : 2020-12-02 Abstract: This document describes the applicability of a hybrid performance measurement method for packet loss and packet delay measurements of a multicast service through a Bit Index Explicit Replication domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bier-pmmm-oam/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bier-pmmm-oam-09 https://datatracker.ietf.org/doc/html/draft-ietf-bier-pmmm-oam-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-pmmm-oam-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 2 13:07:31 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D123B3A14F2; Wed, 2 Dec 2020 13:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=gmail.com 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 hYr9wdlZ1NQj; Wed, 2 Dec 2020 13:07:27 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F6F3A1482; Wed, 2 Dec 2020 13:07:27 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id s27so6956603lfp.5; Wed, 02 Dec 2020 13:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=abPwfRIDXEgpmTJpCx0zRh2S1ryxeSO3zcZ61V4+S3M=; b=Ulu1XRJb4WF3iWRto1iXQsZiTAjyduufR6b8hvwep2VbiW7qnLs/WryBdEqyG8NCaZ 7mfpUXcDsyoAg2nJPVvgnRgbD7wInjgpqEKYYJboZ2ycH5eGszCwD80OdyL5c+oEKAQd ZTbpxKJiLnzsgzP5KSeG3BlTppEya8Pi6fjv4OR6f7iC7ljMYBvp0LF29AKlbbHLmB+A Dq4qioDZ5ibwcX7zESV9NgqvMdXNkxvvwoQP9pAuSQEIuuMeOHQnbn0Qwn4tExp3/MZy tqNQC2/wMwjkgGiHSivSn3lUVBeefQpZzPia/2jAwTX2e77g1ZHu1xRpeddDMu/0462S fKrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=abPwfRIDXEgpmTJpCx0zRh2S1ryxeSO3zcZ61V4+S3M=; b=N4O2tQSEffV7HY9duvnds06ofRXARS6fgXzaOwqbvIrSap+nPLs82DTPztruZD9jCB u3cGPgLLEA4bkIBsCNBFfyRbT9xZisCSNGSfr7V8GXoSJxA25CtgquSQOj8Oyz//hz05 WFfE1BG+/vXy4DlH9Kn5OJZvHWK/wV4ARg7N+2qerXkN6YBiLzM8b5fXsnLvF0H3KG61 6QGBUa7Q9cNJXZItmjNfBcay1tJhVUDCc2f8x7MNY1T79p5eqtNAIV+azGoQFY9cFvL/ Rrlc6SNz1Pq+otiM6Iohia+ShD77ilj0hJSZVMzRhh606Bgv5uSYNHw6bi6tdTwIxGQx ABPg== X-Gm-Message-State: AOAM533MyNY1LZzU4cGnsIrbVR4opG6Cynm2SXUaFxMQAfjGYbmb3aDh 1JewnUTtJrArPEGKnBMlXm+KeRsK8ARWJqnQ7f1EYpBLLz4= X-Google-Smtp-Source: ABdhPJyOTcVPI70i8P4n+y1pQ5e662aK3n6s0Hg4iIYoyORXgQt1q0D0kmqOL7u3l70+2AxukvI1QT2B+cVoYZ7Ba2M= X-Received: by 2002:a19:3f09:: with SMTP id m9mr2066691lfa.433.1606943245054; Wed, 02 Dec 2020 13:07:25 -0800 (PST) MIME-Version: 1.0 References: <160694241984.13930.12312488277059138620@ietfa.amsl.com> In-Reply-To: <160694241984.13930.12312488277059138620@ietfa.amsl.com> From: Greg Mirsky Date: Wed, 2 Dec 2020 13:07:13 -0800 Message-ID: To: BIER WG , BIER WG Chairs Content-Type: multipart/alternative; boundary="0000000000004bb57c05b581a138" Archived-At: Subject: [Bier] Fwd: New Version Notification for draft-ietf-bier-pmmm-oam-09.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 21:07:30 -0000 --0000000000004bb57c05b581a138 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, we've worked on addressing the comments received from our AD and much appreciate your feedback, questions, and suggestion. Some questions raised by Alvaro in AD's review are yet to be closed : 1. Track: Experimental, Informational, or Standard? - RFC 8321 is Experimental. Alvaro has pointed that =E2=80=9Cgiven th= at rfc8321 is not mature enough, what should be the Status of this document: Experimental or Informational?=E2=80=9D 2. Relationship to draft-ietf-bier-oam-requirements: - Added reference is the right step but not enough - If WG is resolute to publish draft-ietf-bier-oam-requirements, it should progress at least in-step with this draft - Using the OAM field for Marking Method - Could there be other interpretations and use of the OAM field of BIER header or only for the Alt.Marking method? - If the interpretation of the OAM field is only as defined in this draft, then it must be marked as update of RFC 8296. - In any case, IANA Considerations section doesn=E2=80=99t make sens= e - remove 3. Naming flags: - L(oss)/D(elay) vs. S(ingle)/D(ouble) A new text has been added to clarify an operational aspect of using the Alternate Marking method in a BIER domain: NEW TEXT: Selection of a time interval to switch the marking of a batch of packets should be based on the service requirements. In the course of the regular operation, reports, including performance metrics like packet loss ratio, packet delay, and inter-packet delay variation, are logged every 15 minutes. Thus, it is reasonable to maintain the duration of the measurement interval at 5 minutes with 100 measurements per each interval. To support these measurements, marking of the packet batch is switched every 3 seconds. In case when performance metrics are required in near-real-time, the duration interval of a single batch of identically marked packets will be in the range of tens of milliseconds. The authors are looking forward to working on progressing this specification. Regards, Greg ---------- Forwarded message --------- From: Date: Wed, Dec 2, 2020 at 12:53 PM Subject: New Version Notification for draft-ietf-bier-pmmm-oam-09.txt To: Giuseppe Fioccola , Lianshu Zheng < vero.zheng@huawei.com>, Mach Chen , Greg Mirsky < gregimirsky@gmail.com> A new version of I-D, draft-ietf-bier-pmmm-oam-09.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-bier-pmmm-oam Revision: 09 Title: Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer Document date: 2020-12-02 Group: bier Pages: 9 URL: https://www.ietf.org/archive/id/draft-ietf-bier-pmmm-oam-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bier-pmmm-oam/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bier-pmmm-oam Htmlized: https://tools.ietf.org/html/draft-ietf-bier-pmmm-oam-09 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bier-pmmm-oam-09 Abstract: This document describes the applicability of a hybrid performance measurement method for packet loss and packet delay measurements of a multicast service through a Bit Index Explicit Replication domain. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000004bb57c05b581a138 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000004bb57c05b581a138-- From nobody Wed Dec 2 13:23:05 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2B23A17CA for ; Wed, 2 Dec 2020 13:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ys7oPzRksfAE for ; Wed, 2 Dec 2020 13:22:50 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10403A166E for ; Wed, 2 Dec 2020 13:21:13 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id u19so6998829lfr.7 for ; Wed, 02 Dec 2020 13:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cSN2/LLZzYWUpNT3wEpWDUcRP8ugsnVIVMZm/rqdDTo=; b=md/32FEKgtW1qgJB+WcfDADr72ySx59i061/nGqCDYQVmPaoU5cQgWX/nytNQtNR0Q vdXErNvt7orh9C9D+xBOeQhJasLUleNCvIeknxu4Xb5MGxc13h7KWXV4eSBsPP1ebvaB h5ZbwWtCJ9MqUOyUFp7RR3uO8WsKuYATXBD8ql2wQujoaVpCJ0adjzsy3EsZcHH0Jo64 VQMVFfVPUrCPq/aVsYxy2fqSErVHKsfqfx0GCIpwhS0dkVe6hb3gedX90AS1I3+0B5tv JhcY9QZGymvX0ffWIbkn84LWu9sjMevsRIPjKJdyVS+COJekZpCv8gEiKnOoUwdWNh54 UNTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cSN2/LLZzYWUpNT3wEpWDUcRP8ugsnVIVMZm/rqdDTo=; b=qr2YF3P9EJDb1pY+Q/eD694s1ezZZA0vPXiAl3GpypQxIMVO5fBC9PQowfYlnWAHHZ 5SfZpKsrpRqn90oA7SzIgv7mp5QEakEOzJafiQERgAblZ2WQghxOpuukinwpxaTmImCt PA8JcIoEQ8M02xlIuI1X7gJ4HAMlKcfGxKl/aVHDLk/idg20XhmtpKU7mGLMOuFxkXjm H1/HjBnKUOEx1cVJx1Vz2Yv18m/BnnnrxEzt7mfWh9wiSW+RVUgnkcku0RV48ilzzcsP gmgG7IMQ/KqlH+BfFHazSQnjEBXQjUgUSTrZpz9gtlY4+gTgIRnOceC8/9aXl/ZffTUY PwmQ== X-Gm-Message-State: AOAM531E/KW/34Y+M+AyFUVYWOKldxdzU2BGLm6sKnz/0vc/T4zTqogP y/gEK4znZiHS2WbdNQUxHml3TFXd6IuMF+Y8RCc= X-Google-Smtp-Source: ABdhPJzkhlysezws2RxGZR1ZacgyZO5b4bvlE86IrxiC2nZTLmtg/S/0dWexmFrKjqbvWpq+2ANt2/pW8ZRzA18WlU4= X-Received: by 2002:a19:f243:: with SMTP id d3mr5345lfk.534.1606944071699; Wed, 02 Dec 2020 13:21:11 -0800 (PST) MIME-Version: 1.0 References: <00b201d6c70b$0618bae0$124a30a0$@olddog.co.uk> In-Reply-To: <00b201d6c70b$0618bae0$124a30a0$@olddog.co.uk> From: Greg Mirsky Date: Wed, 2 Dec 2020 13:20:59 -0800 Message-ID: To: Adrian Farrel Cc: "Jeffrey (Zhaohui) Zhang" , BIER WG Content-Type: multipart/alternative; boundary="000000000000914ef705b581d27e" Archived-At: Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 21:23:04 -0000 --000000000000914ef705b581d27e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, you've said: This deployment case is somewhat niche: multicast is a bit rare, BIER is not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, bridging over IPv6 is a subset of BIER. I've paused on the second sentence. As I understand it, BIER is designed specifically for multicast. Perhaps it is not yet as widely deployed comparing to the overall multicast deployments but I cannot name what else would benefit from BIER as much as multicast. Is my interpretation close to the idea of that sentence? Regards, Greg On Mon, Nov 30, 2020 at 3:22 AM Adrian Farrel wrote: > Hey Jeffrey, > > It may be because I'm late to the discussion, but when you say... > > > With the above, there is simply no need for another solution in my view= . > > ...this seems to suggest that there is already a solution. > AFAICS, while you might support only one of the two solutions, there are > two solutions. Neither has been adopted and neither has been "selected". > > You might have better phrased this as "this is simply no need for two > solutions." It might be true that most people agree with that, but since > they will only agree if their preferred solution is chosen, it is possibl= y > not very helpful. > > However, you go on... > > > Of course the WG can continue discussing BIERv6 and may determine that > it is > > nice to have BIERv6 as well, but we should not bundle them together whe= n > it > > comes to adoption. > > ...which seems to suggest that you don't think it is harmful to discuss > two solutions. > Since the adoption of one on its own is likely to reduce the chances of > adoption of the other, not bundling the adoptions might be a little > simplistic. I am not proposing that we poll the adoption of either soluti= on > first. Nor am I suggesting making it an either/or adoption poll. > > So how about this? > > - BIER has a history of starting with Experimental work and seeing how it > develops > - This deployment case is somewhat niche: multicast is a bit rare, BIER i= s > not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, > bridging over IPv6 is a subset of BIER. > - Why not adopt both approaches as Experimental and set some clear terms > for the experiment? > > Cheers, > Adrian > > -----Original Message----- > From: BIER On Behalf Of Jeffrey (Zhaohui) Zhang > Sent: 28 November 2020 21:54 > To: Michael McBride ; gjshep@gmail.com > Cc: BIER WG ; Gyan Mishra ; > draft-ietf-bier-ipv6-requirements < > draft-ietf-bier-ipv6-requirements@ietf.org>; EXT-zhang.zheng@zte.com.cn < > zhang.zheng@zte.com.cn>; Alvaro Retana > Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 > > To clarify, there is no gap in the BIERin6 solution (besides the new "nex= t > header" code point). It's just that some text are needed to explain how t= he > requirements are met with the BIERin6 solution - whether it is a > requirement already listed in the current requirements draft, or have bee= n > brought up in recent mailing list discussions (I know of two in recent > discussions). > > BIERin6 is based on RFC 8296 (plus the new "next header" code point for > IPv6 encapsulation), and is a generic solution with the following > properties: > > 1. clean layering - BIER over L2/tunnel and it can carry different payloa= d > types including SRv6 > 2. IPv4/IPv6 independent (of course you need different signaling) > 3. L2 independent - as long as the L2 header can indicate with a code > point that a BIER header follows > 4. tunnel type independent - as long as the tunnel header can indicate > with a code point that a BIER header follows > 5. can work one-hop or multi-hop tunnels nicely > 6. can work with SRv6 based services nicely > > With the above, there is simply no need for another solution in my view. > Of course the WG can continue discussing BIERv6 and may determine that it > is nice to have BIERv6 as well, but we should not bundle them together wh= en > it comes to adoption. That's why I suggested in the last BIER session the > following: > > - Adopt BIERin6 > - Discuss BIERv6 further > > Jeffrey > > -----Original Message----- > From: Michael McBride > Sent: Saturday, November 28, 2020 2:15 PM > To: gjshep@gmail.com; Jeffrey (Zhaohui) Zhang > Cc: Gyan Mishra ; Alvaro Retana < > aretana.ietf@gmail.com>; BIER WG ; > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < > draft-ietf-bier-ipv6-requirements@ietf.org> > Subject: RE: draft-ietf-bier-ipv6-requirements-09 > > [External Email. Be cautious of content] > > > Hi Greg, > > >Thank you Jeffrey and Gyan for sticking with the thread of the > conversation to advance the discussion. It's clear now that all of the > requirements >discussed so far can be addressed by the BIERin6 draft if w= e > flesh out the discussed gaps. > > >I would like to see Jeffrey and Gyan take over as primary authors of > >BIERin6 to include the gaps discussed here so that it fully encompases > the requirements so far described, for WG adoption. > > I'm sure I'm misinterpreting. What it sounds like you are saying is "I > want bierin6 to be adopted so let's fix the gaps so we can begin". Since > both solutions meet the requirements, I'm hoping you meant "Let's fix the > gaps in bierin6 so we can begin adoption calls for both bierv6 and bierin= 6". > > mike > > > On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang < > zzhang@juniper.net> > wrote: > > > Hi Gyan, > > > > > > > > Great that we reached consensus on BIERin6. > > > > Now there are two lingering points alluded to in this thread, but > > given it=E2=80=99s been such a long and deeply nested tread, I=E2=80=99= ll start a new > > thread about it. > > > > > > > > Thanks. > > > > Jeffrey > > > > > > > > *From:* Gyan Mishra > > *Sent:* Monday, November 23, 2020 1:32 AM > > *To:* Jeffrey (Zhaohui) Zhang > > *Cc:* Alvaro Retana ; BIER WG ; > > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < > > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < > > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com > > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 > > > > > > > > *[External Email. Be cautious of content]* > > > > > > > > Hi Jeffrey > > > > > > > > That=E2=80=99s the last of my questions related to BIERin6. > > > > > > > > I thank you for taking the time to go over the BIERin6 draft in detail. > > > > > > > > We have reached consensus as well as are in sync, and I now have a > > better understanding of BIERin6. > > > > > > > > During the discussions I did mention that maybe in BIERin6 optional > > IPv6 tunneling should be removed, as it seemed to create some > > confusion, but now I am clear and as both the L2/tunnel and IPv6 > > L3/tunnel encapsulation single hop or multi hop tunnel both have the > > clean BIER layering and complement each other I agree they belong > together in the same draft. > > > > Even though L2/tunnel exists today as part of RFC8296 it makes sense > > to be part of the overall BIERin6 solution. > > > > > > > > I am clear on the two IANA code points requests required for the > > optional > > IPV6 encapsulation option. > > > > > > > > Over the course of this thread we did touch on some technical reasons > > why > > IPV6 encapsulation is necessary which I you mentioned in some of your > > responses. > > > > > > > > Overall throughout the discussions I agree that BIERin6 IPV6 tunnel > > option and BIERv6 are not transitional and are long term solutions and > > there are reasons why that we can add to the requirements draft as to > > why IPV6 encapsulation is necessary below: > > > > > > > > - Operator requirement for IPV6 encapsulated packets and not L2 > > encapsulation. > > > > -FRR > > > > > > > > I think we are all set to start updating the Requirements draft. > > > > > > > > In-line Gyan6> > > > > > > > > Kind Regards > > > > > > > > Gyan > > > > > > > > On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang < > > zzhang@juniper.net> wrote: > > > > Gyan, > > > > > > > > Please see zzh6> below. > > > > > > > > *From:* Gyan Mishra > > *Sent:* Sunday, November 22, 2020 9:49 PM > > *To:* Jeffrey (Zhaohui) Zhang > > *Cc:* Alvaro Retana ; BIER WG ; > > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < > > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < > > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com > > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 > > > > > > > > *[External Email. Be cautious of content]* > > > > > > > > > > > > Hi Jeffrey > > > > > > > > Agreed we have reached a consensus. > > > > > > > > > > > > Few more questions to iron out understanding. > > > > > > > > In line gyan4> > > > > > > > > Zzh6> Apparently there are still disconnects =F0=9F=98=8A > > > > Gyan> Thank you for all the detailed responses. We are in sync now! > > > > On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang < > > zzhang@juniper.net> wrote: > > > > Hi Gyan, > > > > > > > > Yes I believe we=E2=80=99ve reached consensus. > > > > > > > > Please see zzh5> below about some details. > > > > > > > > *From:* Gyan Mishra > > *Sent:* Sunday, November 22, 2020 4:19 PM > > *To:* Jeffrey (Zhaohui) Zhang > > *Cc:* Alvaro Retana ; BIER WG ; > > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < > > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < > > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com > > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 > > > > > > > > *[External Email. Be cautious of content]* > > > > > > > > Hi Jeffrey > > > > > > > > This has been a very informative exchange and extremely helpful for > > all of us to get onto the same page from a basic understanding POV. > > > > > > > > Much appreciated all your help and feedback helping clarify my confusio= n. > > > > > > > > I am answering in-line but now connecting the dots how is in today=E2= =80=99s > > RFC > > 8296 Non MPLS BIER Ethernet going to transport IPv6? > > > > > > > > From your answers below it cannot work as we need two IANA code point > > one for IPv6 next header type and ICMPv6. > > > > > > > > Zzh5> The existing model/concept works except that we need to two code > > points if IPv6 tunneling is used for either getting over non-BFRs or > > for FRR. One may deem non-BFR as a short-term scenario but FRR will be > > here for the long run. > > > > > > > > Gyan4>I am a little confused here with the code points. For > > BIERin6 =E2=80=9CL2=E2=80=9D BIER scenario RFC 8296 Non MPLS BIER Ether= net Ether type > 0xAB37. > > > > > > > > Ethernet -0xAB37 l BIER | IPv6 | payload > > > > > > > > Zzh6> Note that IPv6 header is not needed =E2=80=93 it should be Ethern= et > > Zzh6> -0xAB37 > > l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6 > > header may be inserted between BIER and payload, only for the SRv6 > > style VPN purpose. > > > > Gyan> Understood > > > > Ethernet -0xAB37 l BIER l ICMPv6 | payload > > > > > > > > Zzh6> ICMP was mentioned not for encapsulation but for the following: > > > > Gyan6>Understood > > > > Zzh6> 2.1. IPv6 Options Considerations > > > > > > > > For directly connected BIER routers, IPv6 Hop-by-Hop or Destination > > > > options are irrelevant and SHOULD NOT be inserted by BFIR on the > > > > BIERin6 packet. In this case IPv6 header, Next Header field should > > > > be set to TBD. Any IPv6 packet arriving on BFRs and BFERs, with > > > > multiple extension header where the last extension header has a > > Next > > > > Header field set to TBD, SHOULD be discard and the node should > > > > transmit an ICMP Parameter Problem message to the source of the > > > > packet (BFIR) with an ICMP code value of TBD10 ('invalid options > > for > > > > BIERin6'). > > > > > > > > In this particular scenario where adjacent BFRs support Ethernet link > > layer in an IPV6 environment and IPv6 or ICMPv6 encapsulation and the > > need for the next header code point above is the packet format: > > > > > > > > Excerpt from RFC 8296 > > > > > > > > Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet > > > > header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332 > > > k.com/?url=3Dhttps*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cet= p > > u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$ > > defense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!! > > NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8 > > 4ssHlj%24&data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7C97b8a3= 4 > > 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7 > > C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D8EiHsMns5Ju= t > > 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&reserved=3D0>]. IEEE > > > > has assigned Ethertype 0xAB37 for non-MPLS BIER packets. > > > > > > > > > > > > In the case of BIERin6 optional encapsulation option, in case where > > operators requires packets forwarded in IPv6 or tunneling over Non BFR > > packet format below: > > > > > > > > IPv6 outer header l BIER l Data > > > > > > > > So here the next header is BIER so corresponding next header code point= . > > > > > > > > > > > > So below is for both cases IANA code point allocation for =E2=80=9CL2= =E2=80=9D next > > header where next header is IPv6 or ICMPV6, and then the optional IPv6 > > encapsulation option where the next header is BIER. > > > > > > > > Would those be two separate IANA code point requests I what I see from > > the packet format. > > > > > > > > IANA L2 scenario: > > > > 2 code point requests for L2 for next header IPv6 and ICMP > > > > > > > > Zzh6> I don=E2=80=99t follow what you=E2=80=99re talking about. If BIER= header follows > > Zzh6> L2 > > header directly, no new code point is needed. It=E2=80=99s just =E2=80= =9CEthernet > > 0xAB37 | BIER | payload=E2=80=9D. > > > > > > > > Gyan6> Agreed. > > > > > > > > IANA optional IPv6 scenario: > > > > 1 code point request for IPv6 for next header BIER > > > > > > > > Zzh6> If IPv6 encapsulation is used, either on between directly > > Zzh6> connected > > BFRs or indirectly connected BFRs, a new =E2=80=9Cnext header=E2=80=9D = code point is > > needed for BIER. > > > > Gyan6>Understood > > > > > > 5 > > < > https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.co= m/?url=3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2F= html*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpn= hYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24&data=3D04*7C0= 1*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7C0f= ee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7CTWF= pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D= *7C1000&sdata=3DnEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&rese= rved=3D0__;JSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP= 2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N$ > >. > > IANA Considerations > > > > > > > > > > > > IANA is requested to assign a new "BIER" type for "Next Header" in > > > > the "Assigned Internet Protocol Numbers" registry. > > > > > > > > IANA is requested to assign a new "BIERin6" type for "invalid > > > > options" in the "ICMP code value" registry. > > > > > > > > IANA is requested to assign a new "BIER IPv6 transportation > > Sub-sub- > > > > TLV" type in the "OSPFv3 BIER Ethernet Encapsulation sub-TLV" > > > > Registry. > > > > > > > > IANA is requested to set up a new "BIER IPv6 transportation > > Sub-sub- > > > > sub-TLV" type in the "IS-IS BIER Ethernet Encapsulation sub-sub-TLV" > > > > Registry. > > > > > > > > > > > > My point is that the IANA allocation is different as the next header > > is different for the L2 scenario where next header is IPv6 or ICMPV6, > > and IPv6 encapsulation scenario where the next header is BIER. > > > > > > > > Zzh6> If BIER header follows L2 header directly, BIER Ethertype is > > Zzh6> used > > (assuming Ethernet is the L2). > > > > Gyan>Understood > > > > Based on this point I am making could we just do a RFC8296 bis version > > and add the IANA code points for IPv6 and ICMPv6. > > > > > > > > Zzh6> Given the confusion/contention that have happened in the last > > Zzh6> two > > years, it is much better to specifically have a spec dedicated to > > supporting BIER in IPv6. > > > > Gyan6> I think now looking at it holistically speaking I can now see > > parity between the L2/tunnel and L3/tunnel both also having the clean > > layering. So I can see why adding existing L2/tunnel to BIERin6 even > > though it already exists made sense to bundle into BIERin6 total > > solution > > Juniper Business Use Only > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --000000000000914ef705b581d27e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,
you've said:
This deployment case i= s somewhat niche: multicast is a bit rare, BIER is not widely deployed for = multicast, IPv6 is still (sadly) not ubiquitous, bridging over IPv6 is a su= bset of BIER.=C2=A0
I've paused on the second sentenc= e. As I understand it, BIER is designed specifically for multicast. Perhaps= it is not yet as widely deployed comparing to the overall multicast deploy= ments but I cannot name what else would benefit from BIER as much as multic= ast. Is my interpretation close to the idea of that sentence?

Regards,
Greg
Dear All,
=C2=A0 =C2=A01. Track: Experimental, Informati= onal, or Standard?
=C2=A0 =C2=A0 =C2=A0 - RFC 8321 is Experimental. Alva= ro has pointed that =E2=80=9Cgiven that
=C2=A0 =C2=A0 =C2=A0 rfc8321 is = not mature enough, what should be the Status of this document:
=C2=A0 = =C2=A0 =C2=A0 Experimental or Informational?=E2=80=9D
=C2=A0 =C2=A02. Re= lationship to draft-ietf-bier-oam-requirements:
=C2=A0 =C2=A0 =C2=A0 - A= dded reference is the right step but not enough
=C2=A0 =C2=A0 =C2=A0 - I= f WG is resolute to publish draft-ietf-bier-oam-requirements, it
=C2=A0 = =C2=A0 =C2=A0 should progress at least in-step with this draft
=C2=A0 = =C2=A0 =C2=A0 - Using the OAM field for Marking Method
=C2=A0 =C2=A0 =C2= =A0 - Could there be other interpretations and use of the OAM field of
= =C2=A0 =C2=A0 =C2=A0 BIER header or only for the Alt.Marking method?
=C2= =A0 =C2=A0 =C2=A0 - If the interpretation of the OAM field is only as defin= ed in this
=C2=A0 =C2=A0 =C2=A0 draft, then it must be marked as update = of RFC 8296.
=C2=A0 =C2=A0 =C2=A0 - =C2=A0In any case, IANA Consideratio= ns section doesn=E2=80=99t make sense -
=C2=A0 =C2=A0 =C2=A0 remove
= =C2=A0 =C2=A03. Naming flags:
=C2=A0 =C2=A0 =C2=A0 - L(oss)/D(elay) vs. = S(ingle)/D(ouble)
A new text has been added to clarify an ope= rational aspect of using the Alternate Marking method in a BIER domain:
NEW TEXT:
=C2=A0 =C2=A0Selection of a time interval to switch the= marking of a batch of
=C2=A0 =C2=A0packets should be based on the servi= ce requirements.=C2=A0 In the course
=C2=A0 =C2=A0of the regular operati= on, reports, including performance metrics like
=C2=A0 =C2=A0packet loss= ratio, packet delay, and inter-packet delay variation,
=C2=A0 =C2=A0are= logged every 15 minutes.=C2=A0 Thus, it is reasonable to maintain the
= =C2=A0 =C2=A0duration of the measurement interval at 5 minutes with 100
= =C2=A0 =C2=A0measurements per each interval.=C2=A0 To support these measure= ments,
=C2=A0 =C2=A0marking of the packet batch is switched every 3 seco= nds.=C2=A0 In case
=C2=A0 =C2=A0when performance metrics are required in= near-real-time, the duration
=C2=A0 =C2=A0interval of a single batch of= identically marked packets will be in
=C2=A0 =C2=A0the range of tens of= milliseconds.

=C2=A0The authors are looking f= orward to working on progressing this specification.

Regards,
Greg

---------- Forwarded message ---------
From: <internet-dr= afts@ietf.org>
Date: Wed, Dec 2, 2020 at 12:53 PM
Subje= ct: New Version Notification for draft-ietf-bier-pmmm-oam-09.txt
To: Giu= seppe Fioccola <giuseppe= .fioccola@huawei.com>, Lianshu Zheng <vero.zheng@huawei.com>, Mach Chen <mach.chen@huawei.com>, Greg Mirsky <gregimirsky@gmail.com>
=


A new version of I-D, draft-ietf-bier-pmmm-oam-09.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bier-pmmm-oam
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A009
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Performance Measurement (PM) with = Marking Method in Bit Index Explicit Replication (BIER) Layer
Document date:=C2=A0 2020-12-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bier
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-ietf-bier-pmmm-oam-09.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-ietf-bier-pmmm-oam/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/html/draft-ietf-bier-pmmm-oam
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://t= ools.ietf.org/html/draft-ietf-bier-pmmm-oam-09
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bier-pmmm-oam-09

Abstract:
=C2=A0 =C2=A0This document describes the applicability of a hybrid performa= nce
=C2=A0 =C2=A0measurement method for packet loss and packet delay measuremen= ts of a
=C2=A0 =C2=A0multicast service through a Bit Index Explicit Replication dom= ain.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



On Mon, Nov 30, 2020 at 3:22 A= M Adrian Farrel <adrian@olddog.co= .uk> wrote:
Hey Jeffrey,

It may be because I'm late to the discussion, but when you say...

> With the above, there is simply no need for another solution in my vie= w.

...this seems to suggest that there is already a solution.
AFAICS, while you might support only one of the two solutions, there are tw= o solutions. Neither has been adopted and neither has been "selected&q= uot;.

You might have better phrased this as "this is simply no need for two = solutions." It might be true that most people agree with that, but sin= ce they will only agree if their preferred solution is chosen, it is possib= ly not very helpful.

However, you go on...

> Of course the WG can continue discussing BIERv6 and may determine that= it is
> nice to have BIERv6 as well, but we should not bundle them together wh= en it
> comes to adoption.

...which seems to suggest that you don't think it is harmful to discuss= two solutions.
Since the adoption of one on its own is likely to reduce the chances of ado= ption of the other, not bundling the adoptions might be a little simplistic= . I am not proposing that we poll the adoption of either solution first. No= r am I suggesting making it an either/or adoption poll.

So how about this?

- BIER has a history of starting with Experimental work and seeing how it d= evelops
- This deployment case is somewhat niche: multicast is a bit rare, BIER is = not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, br= idging over IPv6 is a subset of BIER.
- Why not adopt both approaches as Experimental and set some clear terms fo= r the experiment?

Cheers,
Adrian

-----Original Message-----
From: BIER <b= ier-bounces@ietf.org> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 28 November 2020 21:54
To: Michael McBride <michael.mcbride@futurewei.com>; gjshep@gmail.com
Cc: BIER WG <bier@iet= f.org>; Gyan Mishra <hayabusagsm@gmail.com>; draft-ietf-bier-ipv6-requirem= ents <draft-ietf-bier-ipv6-requirements@ietf.org>; EXT-zhang.zheng@zt= e.com.cn <zhang.zheng@zte.com.cn>; Alvaro Retana <aretana.ietf@gmail.com>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

To clarify, there is no gap in the BIERin6 solution (besides the new "= next header" code point). It's just that some text are needed to e= xplain how the requirements are met with the BIERin6 solution - whether it = is a requirement already listed in the current requirements draft, or have = been brought up in recent mailing list discussions (I know of two in recent= discussions).

BIERin6 is based on RFC 8296 (plus the new "next header" code poi= nt for IPv6 encapsulation), and is a generic solution with the following pr= operties:

1. clean layering - BIER over L2/tunnel and it can carry different payload = types including SRv6
2. IPv4/IPv6 independent (of course you need different signaling)
3. L2 independent - as long as the L2 header can indicate with a code point= that a BIER header follows
4. tunnel type independent - as long as the tunnel header can indicate with= a code point that a BIER header follows
5. can work one-hop or multi-hop tunnels nicely
6. can work with SRv6 based services nicely

With the above, there is simply no need for another solution in my view. Of= course the WG can continue discussing BIERv6 and may determine that it is = nice to have BIERv6 as well, but we should not bundle them together when it= comes to adoption. That's why I suggested in the last BIER session the= following:

- Adopt BIERin6
- Discuss BIERv6 further

Jeffrey

-----Original Message-----
From: Michael McBride <michael.mcbride@futurewei.com>
Sent: Saturday, November 28, 2020 2:15 PM
To: gjshep@gmail.com<= /a>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Alvaro Retana <aretana.ietf@gmail.com>; BIER = WG <bier@ietf.org= >; EXT-z= hang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <tonysietf@gmail.com&g= t;; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-require= ments@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]


Hi Greg,

>Thank you Jeffrey and Gyan for sticking with the thread of the conversa= tion to advance the discussion. It's clear now that all of the requirem= ents >discussed so far can be addressed by the BIERin6 draft if we flesh= out the discussed gaps.

>I would like to see Jeffrey and Gyan take over as primary authors of >BIERin6 to include the gaps discussed here so that it fully encompases = the requirements so far described, for WG adoption.

I'm sure I'm misinterpreting. What it sounds like you are saying is= "I want bierin6 to be adopted so let's fix the gaps so we can beg= in". Since both solutions meet the requirements, I'm hoping you me= ant "Let's fix the gaps in bierin6 so we can begin adoption calls = for both bierv6 and bierin6".

mike


On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Hi Gyan,
>
>
>
> Great that we reached consensus on BIERin6.
>
> Now there are two lingering points alluded to in this thread, but
> given it=E2=80=99s been such a long and deeply nested tread, I=E2=80= =99ll start a new
> thread about it.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Monday, November 23, 2020 1:32 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> That=E2=80=99s the last of my questions related to BIERin6.
>
>
>
> I thank you for taking the time to go over the BIERin6 draft in detail= .
>
>
>
> We have reached consensus as well as are in sync,=C2=A0 and I now have= a
> better understanding of BIERin6.
>
>
>
> During the discussions I did mention that maybe in BIERin6 optional > IPv6 tunneling should be removed, as it seemed to create some
> confusion, but now I am clear and as both the L2/tunnel and IPv6
> L3/tunnel encapsulation single hop or multi hop tunnel both have the > clean BIER layering and complement each other I agree they belong toge= ther in the same draft.
>
> Even though L2/tunnel exists today as part of RFC8296 it makes sense > to be part of the overall BIERin6 solution.
>
>
>
> I am clear on the two IANA code points requests required for the
> optional
> IPV6 encapsulation option.
>
>
>
> Over the course of this thread we did touch on some technical reasons<= br> > why
> IPV6 encapsulation is necessary which I you mentioned in some of your<= br> > responses.
>
>
>
> Overall throughout the discussions I agree that BIERin6 IPV6 tunnel > option and BIERv6 are not transitional and are long term solutions and=
> there are reasons why that we can add to the requirements draft as to<= br> > why IPV6 encapsulation is necessary below:
>
>
>
> - Operator requirement for IPV6 encapsulated packets=C2=A0 and not L2<= br> > encapsulation.
>
> -FRR
>
>
>
> I think we are all set to start updating the Requirements draft.
>
>
>
> In-line Gyan6>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper= .net> wrote:
>
> Gyan,
>
>
>
> Please see zzh6> below.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 9:49 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Agreed we have reached a consensus.
>
>
>
>
>
> Few more questions to iron out understanding.
>
>
>
> In line gyan4>
>
>
>
> Zzh6> Apparently there are still disconnects =F0=9F=98=8A
>
>=C2=A0 Gyan> Thank you for all the detailed responses.=C2=A0 We are = in sync now!
>
> On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper= .net> wrote:
>
> Hi Gyan,
>
>
>
> Yes I believe we=E2=80=99ve reached consensus.
>
>
>
> Please see zzh5> below about some details.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 4:19 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> This has been a very informative exchange and extremely helpful for > all of us to get onto the same page from a basic understanding POV. >
>
>
> Much appreciated all your help and feedback helping clarify my confusi= on.
>
>
>
> I am answering in-line but now connecting the dots how is in today=E2= =80=99s
> RFC
> 8296 Non MPLS BIER Ethernet going to transport IPv6?
>
>
>
> From your answers below it cannot work as we need two IANA code point<= br> > one for IPv6 next header type and ICMPv6.
>
>
>
> Zzh5> The existing model/concept works except that we need to two c= ode
> points if IPv6 tunneling is used for either getting over non-BFRs or > for FRR. One may deem non-BFR as a short-term scenario but FRR will be=
> here for the long run.
>
>
>
>=C2=A0 =C2=A0 =C2=A0Gyan4>I am a little confused here with the code = points.=C2=A0 For
> BIERin6 =E2=80=9CL2=E2=80=9D BIER scenario RFC 8296 Non MPLS BIER Ethe= rnet Ether type 0xAB37.
>
>
>
> Ethernet -0xAB37 l BIER | IPv6 | payload
>
>
>
> Zzh6> Note that IPv6 header is not needed =E2=80=93 it should be Et= hernet
> Zzh6> -0xAB37
> l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6=
> header may be inserted between BIER and payload, only for the SRv6
> style VPN purpose.
>
> Gyan> Understood
>
> Ethernet -0xAB37 l BIER l ICMPv6 | payload
>
>
>
> Zzh6> ICMP was mentioned not for encapsulation but for the followin= g:
>
>=C2=A0 Gyan6>Understood
>
> Zzh6> 2.1.=C2=A0 IPv6 Options Considerations
>
>
>
>=C2=A0 =C2=A0 For directly connected BIER routers, IPv6 Hop-by-Hop or D= estination
>
>=C2=A0 =C2=A0 options are irrelevant and SHOULD NOT be inserted by BFIR= on the
>
>=C2=A0 =C2=A0 BIERin6 packet.=C2=A0 In this case IPv6 header, Next Head= er field should
>
>=C2=A0 =C2=A0 be set to TBD.=C2=A0 Any IPv6 packet arriving on BFRs and= BFERs, with
>
>=C2=A0 =C2=A0 multiple extension header where the last extension header= has a
> Next
>
>=C2=A0 =C2=A0 Header field set to TBD, SHOULD be discard and the node s= hould
>
>=C2=A0 =C2=A0 transmit an ICMP Parameter Problem message to the source = of the
>
>=C2=A0 =C2=A0 packet (BFIR) with an ICMP code value of TBD10 ('inva= lid options
> for
>
>=C2=A0 =C2=A0 BIERin6').
>
>
>
> In this particular scenario where adjacent BFRs support Ethernet link<= br> > layer in an IPV6 environment and=C2=A0 IPv6 or ICMPv6 encapsulation an= d the
> need for the next header code point above is the packet format:
>
>
>
> Excerpt from RFC 8296
>
>
>
>=C2=A0 =C2=A0 Therefore, if a non-MPLS BIER packet is encapsulated in a= n Ethernet
>
>=C2=A0 =C2=A0 header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC53= 32
> <https://urldefense.com= /v3/__https://nam11.safelinks.protection.outloo
> k.com/?url=3Dhtt= ps*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp
> u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$
> de= fense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!!<= br> > NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8=
> 4ssHlj%24&amp;data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7C= 97b8a34
> 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7=
> C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj=
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D8EiHsM= ns5Jut
> 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&amp;reserved=3D0>].=C2=A0 IE= EE
>
>=C2=A0 =C2=A0 has assigned Ethertype 0xAB37 for non-MPLS BIER packets.<= br> >
>
>
>
>
> In the case of BIERin6 optional encapsulation option, in case where > operators requires packets forwarded in IPv6 or tunneling over Non BFR=
> packet format below:
>
>
>
> IPv6 outer header l BIER l Data
>
>
>
> So here the next header is BIER so corresponding next header code poin= t.
>
>
>
>
>
> So below is for both cases IANA code point allocation for =E2=80=9CL2= =E2=80=9D next
> header where next header is IPv6 or ICMPV6, and then the optional IPv6=
> encapsulation option where the next header is BIER.
>
>
>
> Would those be two separate IANA code point requests I what I see from=
> the packet format.
>
>
>
> IANA L2 scenario:
>
> 2 code point requests for L2 for next header IPv6 and ICMP
>
>
>
> Zzh6> I don=E2=80=99t follow what you=E2=80=99re talking about. If = BIER header follows
> Zzh6> L2
> header directly, no new code point is needed. It=E2=80=99s just =E2=80= =9CEthernet
> 0xAB37 | BIER | payload=E2=80=9D.
>
>
>
>=C2=A0 =C2=A0 =C2=A0Gyan6> Agreed.
>
>
>
> IANA optional IPv6 scenario:
>
> 1 code point request for IPv6 for next header BIER
>
>
>
> Zzh6> If IPv6 encapsulation is used, either on between directly
> Zzh6> connected
> BFRs or indirectly connected BFRs, a new =E2=80=9Cnext header=E2=80=9D= code point is
> needed for BIER.
>
>=C2=A0 Gyan6>Understood
>
>
> 5
> <https://urldefense.com/v3/__http= s://nam11.safelinks.protection.outlook.com/?url=3Dhttps*3A*2F*2Furldefense.= com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07= *section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR= 14p1w2ObtXPqQ_dVL5sH*24&amp;data=3D04*7C01*7Cmichael.mcbride*40futurewe= i.com*7C97b8a3414dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc= *7C1*7C0*7C637420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL= CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=3DnEiVnn= CjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&amp;reserved=3D0__;JSUlJSUlJSU= lKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7= s_KsspK1DsMPGcaKe-PHwxls5N$ >.
> IANA Considerations
>
>
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIER" type f= or "Next Header" in
>
>=C2=A0 =C2=A0 the "Assigned Internet Protocol Numbers" regist= ry.
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIERin6" typ= e for "invalid
>
>=C2=A0 =C2=A0 options" in the "ICMP code value" registry= .
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIER IPv6 transpo= rtation
> Sub-sub-
>
>=C2=A0 =C2=A0 TLV" type in the "OSPFv3 BIER Ethernet Encapsul= ation sub-TLV"
>
>=C2=A0 =C2=A0 Registry.
>
>
>
>=C2=A0 =C2=A0 IANA is requested to set up a new "BIER IPv6 transpo= rtation
> Sub-sub-
>
>=C2=A0 =C2=A0 sub-TLV" type in the "IS-IS BIER Ethernet Encap= sulation sub-sub-TLV"
>
>=C2=A0 =C2=A0 Registry.
>
>
>
>
>
> My point is that the IANA allocation is different as the next header > is different for the L2 scenario where next header is IPv6 or ICMPV6,<= br> > and IPv6 encapsulation scenario where the next header is BIER.
>
>
>
> Zzh6> If BIER header follows L2 header directly, BIER Ethertype is<= br> > Zzh6> used
> (assuming Ethernet is the L2).
>
>=C2=A0 Gyan>Understood
>
> Based on this point I am making could we just do a RFC8296 bis version=
> and add the IANA code points for IPv6 and ICMPv6.
>
>
>
> Zzh6> Given the confusion/contention that have happened in the last=
> Zzh6> two
> years, it is much better to specifically have a spec dedicated to
> supporting BIER in IPv6.
>
>=C2=A0 Gyan6> I think now looking at it holistically speaking I can = now see
> parity between the L2/tunnel and L3/tunnel both also having the clean<= br> > layering.=C2=A0 So I can see why adding existing L2/tunnel to BIERin6 = even
> though it already exists made sense to bundle into BIERin6 total
> solution

Juniper Business Use Only
_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier
--000000000000914ef705b581d27e-- From nobody Wed Dec 2 14:03:29 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80F63A148B for ; Wed, 2 Dec 2020 14:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=unavailable 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 x3OgjdAnlaJ7 for ; Wed, 2 Dec 2020 14:03:22 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 776943A1574 for ; Wed, 2 Dec 2020 14:03:21 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0B2M3HXu025013; Wed, 2 Dec 2020 22:03:17 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DA37922044; Wed, 2 Dec 2020 22:03:16 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id C46F622042; Wed, 2 Dec 2020 22:03:16 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.113.187.83]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0B2M3FNx016100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Dec 2020 22:03:16 GMT Reply-To: From: "Adrian Farrel" To: "'Greg Mirsky'" Cc: "'Jeffrey \(Zhaohui\) Zhang'" , "'BIER WG'" References: <00b201d6c70b$0618bae0$124a30a0$@olddog.co.uk> In-Reply-To: Date: Wed, 2 Dec 2020 22:03:14 -0000 Organization: Old Dog Consulting Message-ID: <05a401d6c8f6$ef05c0d0$cd114270$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05A5_01D6C8F6.EF080AC0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJW4ZgcgJn9V6dtIlaK/47czvNh1wI+2D1AAaHzvMkCg6m8WQJor+VeAn+qBWsBhqizzgF2sxyTAhoEi3kBw2p1GAIQR4u8AXFrCuYCDIbnLAGRhkDVAkjSWykBz+1TMgFD2kUYAlRGkDmn3F8ssA== Content-Language: en-gb X-Originating-IP: 87.113.187.83 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25826.003 X-TM-AS-Result: No--17.208-10.0-31-10 X-imss-scan-details: No--17.208-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25826.003 X-TMASE-Result: 10--17.207600-10.000000 X-TMASE-MatchedRID: Z/tjqhsgM6c7iuZ/mdYYtto4g/Zvpl9fzQnAOmXc4+8vFVlXAdCj7t5w lRG2SS/7xQbvUQrrEmu7B1QwzOcQDxmyTBaqiJvcBthzL1hCXp6cXiJ1NInet41LljL0JaD8Kgu tQn96kgCtQolBQSzokl+aAE9s43Uu53Y+PMaaD+hfSwksvnOsmtsS2M9fXEk9G8xVbO3cCYsJf2 yCIMxU3lDqf+tE0BQqVV4ZZmbE3Yz4uJ1REX4MHT+FxPbxImzyBiP4/1d95JDkUbyaeadtY41cQ lEzGisRHr7f3m7Q7g2qNnzrkU+2mlQQ0EgzIoPRqr3CBdU3C2BAGSnh5QXxviVXoTW0XesnJ2Bf 9jrG3zeTSgZu+40tmQrgwFF/sjum5RMDFPANjSgS39b8+3nDx/4PdEuhNbfd+hpsmOT8p36cLBl 4j9jueM4hSgMUe1DUC/xRU+mwjW88lvugAFiFPxKAWnKBwBf/0qCTqDfPvDGnr9Q3BmJCF/oCl7 AdFElw2X53LeVAc3GmAgeB6dclcmgII9q1LGOVHDQcqEqNN+lhejp7pwzKTJ+MUhNfQe6RmNG// eCbQoXsFE9uzGPsdMzWN98iBBeG3fr9HCSInR9+SLLtNOiBhtkbVxyiYfRTlLjPe4exkC7f76gd Tjr7dU6GAy2sNm/C7spMO3HwKCABmf/gD11vZHTcRTxyvO5LIzTKfEaqKQMsvuYB5U6pR+R0z7l G+jOuA6Zokg/4B2+prpImTnz4tlFH/t3Gql8CuSti1BoHqPYCGnHd1O8XXwzg2awlUpqNGA0H/z LXPxBtNLAj8DYO8KOknopQLzTuVhuZcZ9e/lWbKItl61J/yZUdXE/WGn0Fb1YojBSKEaynmxwsc wVeE7mjfIGRDEdmsOzOncrmCoOFR9Hau8GO7hiF0nj4NPAeavXnkNfs2YC+K4r7sJzpMya10AZK +lJQlr/nowM1sIgKIXCswIlQr2rfgiF0yjFwklSQChP5MO1ejeD7D4untqUgZdIaXg4f X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 22:03:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05A5_01D6C8F6.EF080AC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Typo well caught. =20 Read =E2=80=9CBIER is not widely deployed=E2=80=9D =20 A =20 From: Greg Mirsky =20 Sent: 02 December 2020 21:21 To: Adrian Farrel Cc: Jeffrey (Zhaohui) Zhang ; = BIER WG Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 =20 Hi Adrian, you've said: This deployment case is somewhat niche: multicast is a bit rare, BIER is = not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, = bridging over IPv6 is a subset of BIER.=20 I've paused on the second sentence. As I understand it, BIER is designed = specifically for multicast. Perhaps it is not yet as widely deployed = comparing to the overall multicast deployments but I cannot name what = else would benefit from BIER as much as multicast. Is my interpretation = close to the idea of that sentence? =20 Regards, Greg =20 On Mon, Nov 30, 2020 at 3:22 AM Adrian Farrel > wrote: Hey Jeffrey, It may be because I'm late to the discussion, but when you say... > With the above, there is simply no need for another solution in my = view. ...this seems to suggest that there is already a solution. AFAICS, while you might support only one of the two solutions, there are = two solutions. Neither has been adopted and neither has been "selected". You might have better phrased this as "this is simply no need for two = solutions." It might be true that most people agree with that, but since = they will only agree if their preferred solution is chosen, it is = possibly not very helpful. However, you go on... > Of course the WG can continue discussing BIERv6 and may determine that = it is > nice to have BIERv6 as well, but we should not bundle them together = when it > comes to adoption. ...which seems to suggest that you don't think it is harmful to discuss = two solutions. Since the adoption of one on its own is likely to reduce the chances of = adoption of the other, not bundling the adoptions might be a little = simplistic. I am not proposing that we poll the adoption of either = solution first. Nor am I suggesting making it an either/or adoption = poll. So how about this? - BIER has a history of starting with Experimental work and seeing how = it develops - This deployment case is somewhat niche: multicast is a bit rare, BIER = is not widely deployed for multicast, IPv6 is still (sadly) not = ubiquitous, bridging over IPv6 is a subset of BIER. - Why not adopt both approaches as Experimental and set some clear terms = for the experiment? Cheers, Adrian -----Original Message----- From: BIER > On = Behalf Of Jeffrey (Zhaohui) Zhang Sent: 28 November 2020 21:54 To: Michael McBride >; gjshep@gmail.com = =20 Cc: BIER WG >; Gyan Mishra = >; = draft-ietf-bier-ipv6-requirements = >; = EXT-zhang.zheng@zte.com.cn = >; Alvaro Retana = > Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 To clarify, there is no gap in the BIERin6 solution (besides the new = "next header" code point). It's just that some text are needed to = explain how the requirements are met with the BIERin6 solution - whether = it is a requirement already listed in the current requirements draft, or = have been brought up in recent mailing list discussions (I know of two = in recent discussions). BIERin6 is based on RFC 8296 (plus the new "next header" code point for = IPv6 encapsulation), and is a generic solution with the following = properties: 1. clean layering - BIER over L2/tunnel and it can carry different = payload types including SRv6 2. IPv4/IPv6 independent (of course you need different signaling) 3. L2 independent - as long as the L2 header can indicate with a code = point that a BIER header follows 4. tunnel type independent - as long as the tunnel header can indicate = with a code point that a BIER header follows 5. can work one-hop or multi-hop tunnels nicely 6. can work with SRv6 based services nicely With the above, there is simply no need for another solution in my view. = Of course the WG can continue discussing BIERv6 and may determine that = it is nice to have BIERv6 as well, but we should not bundle them = together when it comes to adoption. That's why I suggested in the last = BIER session the following: - Adopt BIERin6 - Discuss BIERv6 further Jeffrey -----Original Message----- From: Michael McBride > Sent: Saturday, November 28, 2020 2:15 PM To: gjshep@gmail.com ; Jeffrey (Zhaohui) Zhang = > Cc: Gyan Mishra >; = Alvaro Retana >; = BIER WG >; = EXT-zhang.zheng@zte.com.cn = >; Tony = Przygienda >; = draft-ietf-bier-ipv6-requirements = > Subject: RE: draft-ietf-bier-ipv6-requirements-09 [External Email. Be cautious of content] Hi Greg, >Thank you Jeffrey and Gyan for sticking with the thread of the = conversation to advance the discussion. It's clear now that all of the = requirements >discussed so far can be addressed by the BIERin6 draft if = we flesh out the discussed gaps. >I would like to see Jeffrey and Gyan take over as primary authors of >BIERin6 to include the gaps discussed here so that it fully encompases = the requirements so far described, for WG adoption. I'm sure I'm misinterpreting. What it sounds like you are saying is "I = want bierin6 to be adopted so let's fix the gaps so we can begin". Since = both solutions meet the requirements, I'm hoping you meant "Let's fix = the gaps in bierin6 so we can begin adoption calls for both bierv6 and = bierin6". mike On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang = > wrote: > Hi Gyan, > > > > Great that we reached consensus on BIERin6. > > Now there are two lingering points alluded to in this thread, but > given it=E2=80=99s been such a long and deeply nested tread, = I=E2=80=99ll start a new > thread about it. > > > > Thanks. > > Jeffrey > > > > *From:* Gyan Mishra > > *Sent:* Monday, November 23, 2020 1:32 AM > *To:* Jeffrey (Zhaohui) Zhang > > *Cc:* Alvaro Retana >; BIER WG >; > EXT-zhang.zheng@zte.com.cn = >; Tony = Przygienda < > tonysietf@gmail.com >; = draft-ietf-bier-ipv6-requirements < > draft-ietf-bier-ipv6-requirements@ietf.org = >; gjshep@gmail.com = =20 > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 > > > > *[External Email. Be cautious of content]* > > > > Hi Jeffrey > > > > That=E2=80=99s the last of my questions related to BIERin6. > > > > I thank you for taking the time to go over the BIERin6 draft in = detail. > > > > We have reached consensus as well as are in sync, and I now have a > better understanding of BIERin6. > > > > During the discussions I did mention that maybe in BIERin6 optional > IPv6 tunneling should be removed, as it seemed to create some > confusion, but now I am clear and as both the L2/tunnel and IPv6 > L3/tunnel encapsulation single hop or multi hop tunnel both have the > clean BIER layering and complement each other I agree they belong = together in the same draft. > > Even though L2/tunnel exists today as part of RFC8296 it makes sense > to be part of the overall BIERin6 solution. > > > > I am clear on the two IANA code points requests required for the > optional > IPV6 encapsulation option. > > > > Over the course of this thread we did touch on some technical reasons > why > IPV6 encapsulation is necessary which I you mentioned in some of your > responses. > > > > Overall throughout the discussions I agree that BIERin6 IPV6 tunnel > option and BIERv6 are not transitional and are long term solutions and > there are reasons why that we can add to the requirements draft as to > why IPV6 encapsulation is necessary below: > > > > - Operator requirement for IPV6 encapsulated packets and not L2 > encapsulation. > > -FRR > > > > I think we are all set to start updating the Requirements draft. > > > > In-line Gyan6> > > > > Kind Regards > > > > Gyan > > > > On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang < > zzhang@juniper.net > wrote: > > Gyan, > > > > Please see zzh6> below. > > > > *From:* Gyan Mishra > > *Sent:* Sunday, November 22, 2020 9:49 PM > *To:* Jeffrey (Zhaohui) Zhang > > *Cc:* Alvaro Retana >; BIER WG >; > EXT-zhang.zheng@zte.com.cn = >; Tony = Przygienda < > tonysietf@gmail.com >; = draft-ietf-bier-ipv6-requirements < > draft-ietf-bier-ipv6-requirements@ietf.org = >; gjshep@gmail.com = =20 > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 > > > > *[External Email. Be cautious of content]* > > > > > > Hi Jeffrey > > > > Agreed we have reached a consensus. > > > > > > Few more questions to iron out understanding. > > > > In line gyan4> > > > > Zzh6> Apparently there are still disconnects =F0=9F=98=8A > > Gyan> Thank you for all the detailed responses. We are in sync now! > > On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang < > zzhang@juniper.net > wrote: > > Hi Gyan, > > > > Yes I believe we=E2=80=99ve reached consensus. > > > > Please see zzh5> below about some details. > > > > *From:* Gyan Mishra > > *Sent:* Sunday, November 22, 2020 4:19 PM > *To:* Jeffrey (Zhaohui) Zhang > > *Cc:* Alvaro Retana >; BIER WG >; > EXT-zhang.zheng@zte.com.cn = >; Tony = Przygienda < > tonysietf@gmail.com >; = draft-ietf-bier-ipv6-requirements < > draft-ietf-bier-ipv6-requirements@ietf.org = >; gjshep@gmail.com = =20 > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 > > > > *[External Email. Be cautious of content]* > > > > Hi Jeffrey > > > > This has been a very informative exchange and extremely helpful for > all of us to get onto the same page from a basic understanding POV. > > > > Much appreciated all your help and feedback helping clarify my = confusion. > > > > I am answering in-line but now connecting the dots how is in = today=E2=80=99s > RFC > 8296 Non MPLS BIER Ethernet going to transport IPv6? > > > > From your answers below it cannot work as we need two IANA code point > one for IPv6 next header type and ICMPv6. > > > > Zzh5> The existing model/concept works except that we need to two code > points if IPv6 tunneling is used for either getting over non-BFRs or > for FRR. One may deem non-BFR as a short-term scenario but FRR will be > here for the long run. > > > > Gyan4>I am a little confused here with the code points. For > BIERin6 =E2=80=9CL2=E2=80=9D BIER scenario RFC 8296 Non MPLS BIER = Ethernet Ether type 0xAB37. > > > > Ethernet -0xAB37 l BIER | IPv6 | payload > > > > Zzh6> Note that IPv6 header is not needed =E2=80=93 it should be = Ethernet > Zzh6> -0xAB37 > l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6 > header may be inserted between BIER and payload, only for the SRv6 > style VPN purpose. > > Gyan> Understood > > Ethernet -0xAB37 l BIER l ICMPv6 | payload > > > > Zzh6> ICMP was mentioned not for encapsulation but for the following: > > Gyan6>Understood > > Zzh6> 2.1. IPv6 Options Considerations > > > > For directly connected BIER routers, IPv6 Hop-by-Hop or Destination > > options are irrelevant and SHOULD NOT be inserted by BFIR on the > > BIERin6 packet. In this case IPv6 header, Next Header field should > > be set to TBD. Any IPv6 packet arriving on BFRs and BFERs, with > > multiple extension header where the last extension header has a > Next > > Header field set to TBD, SHOULD be discard and the node should > > transmit an ICMP Parameter Problem message to the source of the > > packet (BFIR) with an ICMP code value of TBD10 ('invalid options > for > > BIERin6'). > > > > In this particular scenario where adjacent BFRs support Ethernet link > layer in an IPV6 environment and IPv6 or ICMPv6 encapsulation and the > need for the next header code point above is the packet format: > > > > Excerpt from RFC 8296 > > > > Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet > > header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332 > =20 > = k.com/?url=3Dhttps*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp = =20 > u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$ > defense.com %2Fv3%2F__https%3A%2Ftools.ietf.org = %2Fhtml%2Frfc5332__%3B!! > NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8 > 4ssHlj%24&data=3D04%7C01%7Cmichael.mcbride%40futurewei.com = %7C97b8a34 > 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7 > C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > = oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D8EiHsMns5Jut > 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&reserved=3D0>]. IEEE > > has assigned Ethertype 0xAB37 for non-MPLS BIER packets. > > > > > > In the case of BIERin6 optional encapsulation option, in case where > operators requires packets forwarded in IPv6 or tunneling over Non BFR > packet format below: > > > > IPv6 outer header l BIER l Data > > > > So here the next header is BIER so corresponding next header code = point. > > > > > > So below is for both cases IANA code point allocation for = =E2=80=9CL2=E2=80=9D next > header where next header is IPv6 or ICMPV6, and then the optional IPv6 > encapsulation option where the next header is BIER. > > > > Would those be two separate IANA code point requests I what I see from > the packet format. > > > > IANA L2 scenario: > > 2 code point requests for L2 for next header IPv6 and ICMP > > > > Zzh6> I don=E2=80=99t follow what you=E2=80=99re talking about. If = BIER header follows > Zzh6> L2 > header directly, no new code point is needed. It=E2=80=99s just = =E2=80=9CEthernet > 0xAB37 | BIER | payload=E2=80=9D. > > > > Gyan6> Agreed. > > > > IANA optional IPv6 scenario: > > 1 code point request for IPv6 for next header BIER > > > > Zzh6> If IPv6 encapsulation is used, either on between directly > Zzh6> connected > BFRs or indirectly connected BFRs, a new =E2=80=9Cnext header=E2=80=9D = code point is > needed for BIER. > > Gyan6>Understood > > > 5 > = . > IANA Considerations > > > > > > IANA is requested to assign a new "BIER" type for "Next Header" in > > the "Assigned Internet Protocol Numbers" registry. > > > > IANA is requested to assign a new "BIERin6" type for "invalid > > options" in the "ICMP code value" registry. > > > > IANA is requested to assign a new "BIER IPv6 transportation > Sub-sub- > > TLV" type in the "OSPFv3 BIER Ethernet Encapsulation sub-TLV" > > Registry. > > > > IANA is requested to set up a new "BIER IPv6 transportation > Sub-sub- > > sub-TLV" type in the "IS-IS BIER Ethernet Encapsulation = sub-sub-TLV" > > Registry. > > > > > > My point is that the IANA allocation is different as the next header > is different for the L2 scenario where next header is IPv6 or ICMPV6, > and IPv6 encapsulation scenario where the next header is BIER. > > > > Zzh6> If BIER header follows L2 header directly, BIER Ethertype is > Zzh6> used > (assuming Ethernet is the L2). > > Gyan>Understood > > Based on this point I am making could we just do a RFC8296 bis version > and add the IANA code points for IPv6 and ICMPv6. > > > > Zzh6> Given the confusion/contention that have happened in the last > Zzh6> two > years, it is much better to specifically have a spec dedicated to > supporting BIER in IPv6. > > Gyan6> I think now looking at it holistically speaking I can now see > parity between the L2/tunnel and L3/tunnel both also having the clean > layering. So I can see why adding existing L2/tunnel to BIERin6 even > though it already exists made sense to bundle into BIERin6 total > solution Juniper Business Use Only _______________________________________________ BIER mailing list BIER@ietf.org =20 https://www.ietf.org/mailman/listinfo/bier _______________________________________________ BIER mailing list BIER@ietf.org =20 https://www.ietf.org/mailman/listinfo/bier ------=_NextPart_000_05A5_01D6C8F6.EF080AC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Typo well = caught.

 

Read = =E2=80=9CBIER is not widely deployed=E2=80=9D

 

A

 

From: Greg Mirsky = <gregimirsky@gmail.com>
Sent: 02 December 2020 = 21:21
To: Adrian Farrel = <adrian@olddog.co.uk>
Cc: Jeffrey (Zhaohui) Zhang = <zzhang=3D40juniper.net@dmarc.ietf.org>; BIER WG = <bier@ietf.org>
Subject: Re: [Bier] = draft-ietf-bier-ipv6-requirements-09

 

Hi = Adrian,

you've = said:

This deployment case is somewhat niche: multicast is a = bit rare, BIER is not widely deployed for multicast, IPv6 is still = (sadly) not ubiquitous, bridging over IPv6 is a subset of = BIER. 

I've = paused on the second sentence. As I understand it, BIER is designed = specifically for multicast. Perhaps it is not yet as widely deployed = comparing to the overall multicast deployments but I cannot name what = else would benefit from BIER as much as multicast. Is my interpretation = close to the idea of that sentence?

 

Regards,

Greg

 

On = Mon, Nov 30, 2020 at 3:22 AM Adrian Farrel <adrian@olddog.co.uk> = wrote:

Hey = Jeffrey,

It may be because I'm late to the discussion, but when = you say...

> With the above, there is simply no need for = another solution in my view.

...this seems to suggest that there = is already a solution.
AFAICS, while you might support only one of = the two solutions, there are two solutions. Neither has been adopted and = neither has been "selected".

You might have better = phrased this as "this is simply no need for two solutions." It = might be true that most people agree with that, but since they will only = agree if their preferred solution is chosen, it is possibly not very = helpful.

However, you go on...

> Of course the WG can = continue discussing BIERv6 and may determine that it is
> nice to = have BIERv6 as well, but we should not bundle them together when = it
> comes to adoption.

...which seems to suggest that you = don't think it is harmful to discuss two solutions.
Since the = adoption of one on its own is likely to reduce the chances of adoption = of the other, not bundling the adoptions might be a little simplistic. I = am not proposing that we poll the adoption of either solution first. Nor = am I suggesting making it an either/or adoption poll.

So how = about this?

- BIER has a history of starting with Experimental = work and seeing how it develops
- This deployment case is somewhat = niche: multicast is a bit rare, BIER is not widely deployed for = multicast, IPv6 is still (sadly) not ubiquitous, bridging over IPv6 is a = subset of BIER.
- Why not adopt both approaches as Experimental and = set some clear terms for the = experiment?

Cheers,
Adrian

-----Original = Message-----
From: BIER <bier-bounces@ietf.org> On Behalf Of Jeffrey = (Zhaohui) Zhang
Sent: 28 November 2020 21:54
To: Michael McBride = <michael.mcbride@futurewei.com>; gjshep@gmail.com
Cc: BIER WG <bier@ietf.org>; = Gyan Mishra <hayabusagsm@gmail.com>; = draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Alvaro Retana <aretana.ietf@gmail.com>
Subject: Re: [Bier] = draft-ietf-bier-ipv6-requirements-09

To clarify, there is no gap = in the BIERin6 solution (besides the new "next header" code = point). It's just that some text are needed to explain how the = requirements are met with the BIERin6 solution - whether it is a = requirement already listed in the current requirements draft, or have = been brought up in recent mailing list discussions (I know of two in = recent discussions).

BIERin6 is based on RFC 8296 (plus the new = "next header" code point for IPv6 encapsulation), and is a = generic solution with the following properties:

1. clean layering = - BIER over L2/tunnel and it can carry different payload types including = SRv6
2. IPv4/IPv6 independent (of course you need different = signaling)
3. L2 independent - as long as the L2 header can indicate = with a code point that a BIER header follows
4. tunnel type = independent - as long as the tunnel header can indicate with a code = point that a BIER header follows
5. can work one-hop or multi-hop = tunnels nicely
6. can work with SRv6 based services = nicely

With the above, there is simply no need for another = solution in my view. Of course the WG can continue discussing BIERv6 and = may determine that it is nice to have BIERv6 as well, but we should not = bundle them together when it comes to adoption. That's why I suggested = in the last BIER session the following:

- Adopt BIERin6
- = Discuss BIERv6 further

Jeffrey

-----Original = Message-----
From: Michael McBride <michael.mcbride@futurewei.com>
Sent: = Saturday, November 28, 2020 2:15 PM
To: gjshep@gmail.com; = Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>; = EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <tonysietf@gmail.com>; = draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
S= ubject: RE: draft-ietf-bier-ipv6-requirements-09

[External Email. = Be cautious of content]


Hi Greg,

>Thank you Jeffrey = and Gyan for sticking with the thread of the conversation to advance the = discussion. It's clear now that all of the requirements >discussed so = far can be addressed by the BIERin6 draft if we flesh out the discussed = gaps.

>I would like to see Jeffrey and Gyan take over as = primary authors of
>BIERin6 to include the gaps discussed here so = that it fully encompases the requirements so far described, for WG = adoption.

I'm sure I'm misinterpreting. What it sounds like you = are saying is "I want bierin6 to be adopted so let's fix the gaps = so we can begin". Since both solutions meet the requirements, I'm = hoping you meant "Let's fix the gaps in bierin6 so we can begin = adoption calls for both bierv6 and = bierin6".

mike


On Mon, Nov 23, 2020 at 4:56 AM = Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Hi = Gyan,
>
>
>
> Great that we reached consensus on = BIERin6.
>
> Now there are two lingering points alluded to = in this thread, but
> given it=E2=80=99s been such a long and = deeply nested tread, I=E2=80=99ll start a new
> thread about = it.
>
>
>
> Thanks.
>
> = Jeffrey
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Monday, = November 23, 2020 1:32 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana = <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda = <
> tonysietf@gmail.com>; = draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: = draft-ietf-bier-ipv6-requirements-09
>
>
>
> = *[External Email. Be cautious of = content]*
>
>
>
> Hi = Jeffrey
>
>
>
> That=E2=80=99s the last of my = questions related to BIERin6.
>
>
>
> I thank = you for taking the time to go over the BIERin6 draft in = detail.
>
>
>
> We have reached consensus as = well as are in sync,  and I now have a
> better understanding = of BIERin6.
>
>
>
> During the discussions I did = mention that maybe in BIERin6 optional
> IPv6 tunneling should be = removed, as it seemed to create some
> confusion, but now I am = clear and as both the L2/tunnel and IPv6
> L3/tunnel encapsulation = single hop or multi hop tunnel both have the
> clean BIER layering = and complement each other I agree they belong together in the same = draft.
>
> Even though L2/tunnel exists today as part of = RFC8296 it makes sense
> to be part of the overall BIERin6 = solution.
>
>
>
> I am clear on the two IANA = code points requests required for the
> optional
> IPV6 = encapsulation option.
>
>
>
> Over the course of = this thread we did touch on some technical reasons
> why
> = IPV6 encapsulation is necessary which I you mentioned in some of = your
> responses.
>
>
>
> Overall = throughout the discussions I agree that BIERin6 IPV6 tunnel
> = option and BIERv6 are not transitional and are long term solutions = and
> there are reasons why that we can add to the requirements = draft as to
> why IPV6 encapsulation is necessary = below:
>
>
>
> - Operator requirement for IPV6 = encapsulated packets  and not L2
> = encapsulation.
>
> -FRR
>
>
>
> I = think we are all set to start updating the Requirements = draft.
>
>
>
> In-line = Gyan6>
>
>
>
> Kind = Regards
>
>
>
> = Gyan
>
>
>
> On Sun, Nov 22, 2020 at 10:39 PM = Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net> wrote:
>
> = Gyan,
>
>
>
> Please see zzh6> = below.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, = November 22, 2020 9:49 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana = <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda = <
> tonysietf@gmail.com>; = draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: = draft-ietf-bier-ipv6-requirements-09
>
>
>
> = *[External Email. Be cautious of = content]*
>
>
>
>
>
> Hi = Jeffrey
>
>
>
> Agreed we have reached a = consensus.
>
>
>
>
>
> Few more = questions to iron out understanding.
>
>
>
> In = line gyan4>
>
>
>
> Zzh6> Apparently there = are still disconnects 😊
>
>  Gyan> Thank = you for all the detailed responses.  We are in sync = now!
>
> On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) = Zhang <
> zzhang@juniper.net> wrote:
>
> Hi = Gyan,
>
>
>
> Yes I believe we=E2=80=99ve = reached consensus.
>
>
>
> Please see zzh5> = below about some details.
>
>
>
> *From:* Gyan = Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, = November 22, 2020 4:19 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana = <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda = <
> tonysietf@gmail.com>; = draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: = draft-ietf-bier-ipv6-requirements-09
>
>
>
> = *[External Email. Be cautious of = content]*
>
>
>
> Hi = Jeffrey
>
>
>
> This has been a very informative = exchange and extremely helpful for
> all of us to get onto the = same page from a basic understanding = POV.
>
>
>
> Much appreciated all your help and = feedback helping clarify my confusion.
>
>
>
> I = am answering in-line but now connecting the dots how is in = today=E2=80=99s
> RFC
> 8296 Non MPLS BIER Ethernet going to = transport IPv6?
>
>
>
> From your answers below = it cannot work as we need two IANA code point
> one for IPv6 next = header type and ICMPv6.
>
>
>
> Zzh5> The = existing model/concept works except that we need to two code
> = points if IPv6 tunneling is used for either getting over non-BFRs = or
> for FRR. One may deem non-BFR as a short-term scenario but = FRR will be
> here for the long = run.
>
>
>
>     Gyan4>I am a = little confused here with the code points.  For
> BIERin6 = =E2=80=9CL2=E2=80=9D BIER scenario RFC 8296 Non MPLS BIER Ethernet Ether = type 0xAB37.
>
>
>
> Ethernet -0xAB37 l BIER | = IPv6 | payload
>
>
>
> Zzh6> Note that IPv6 = header is not needed =E2=80=93 it should be Ethernet
> Zzh6> = -0xAB37
> l BIER | payload. Of course, if SRv6 style VPN must be = used, then IPv6
> header may be inserted between BIER and payload, = only for the SRv6
> style VPN purpose.
>
> Gyan> = Understood
>
> Ethernet -0xAB37 l BIER l ICMPv6 | = payload
>
>
>
> Zzh6> ICMP was mentioned not = for encapsulation but for the following:
>
>  = Gyan6>Understood
>
> Zzh6> 2.1.  IPv6 Options = Considerations
>
>
>
>    For directly = connected BIER routers, IPv6 Hop-by-Hop or = Destination
>
>    options are irrelevant and = SHOULD NOT be inserted by BFIR on the
>
>    = BIERin6 packet.  In this case IPv6 header, Next Header field = should
>
>    be set to TBD.  Any IPv6 packet = arriving on BFRs and BFERs, with
>
>    multiple = extension header where the last extension header has a
> = Next
>
>    Header field set to TBD, SHOULD be = discard and the node should
>
>    transmit an = ICMP Parameter Problem message to the source of = the
>
>    packet (BFIR) with an ICMP code value = of TBD10 ('invalid options
> for
>
>    = BIERin6').
>
>
>
> In this particular scenario = where adjacent BFRs support Ethernet link
> layer in an IPV6 = environment and  IPv6 or ICMPv6 encapsulation and the
> need = for the next header code point above is the packet = format:
>
>
>
> Excerpt from RFC = 8296
>
>
>
>    Therefore, if a = non-MPLS BIER packet is encapsulated in an = Ethernet
>
>    header, the Ethertype MUST NOT be = 0x8847 or 0x8848 [RFC5332
> <https://urldefense.com/v3/__https://nam11.safelinks.pro= tection.outloo
> k.com/?url=3Dhttps*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcO= U1H95lz8ueSP2Cetp
> = u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$
> defense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!!
> = NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8> 4ssHlj%24&amp;data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7C97b8a34
> = 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7> = C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj> = oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D8EiHsMns5= Jut
> = 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&amp;reserved=3D0>].  = IEEE
>
>    has assigned Ethertype 0xAB37 for = non-MPLS BIER packets.
>
>
>
>
>
> = In the case of BIERin6 optional encapsulation option, in case = where
> operators requires packets forwarded in IPv6 or tunneling = over Non BFR
> packet format = below:
>
>
>
> IPv6 outer header l BIER l = Data
>
>
>
> So here the next header is BIER so = corresponding next header code = point.
>
>
>
>
>
> So below is for = both cases IANA code point allocation for =E2=80=9CL2=E2=80=9D = next
> header where next header is IPv6 or ICMPV6, and then the = optional IPv6
> encapsulation option where the next header is = BIER.
>
>
>
> Would those be two separate IANA = code point requests I what I see from
> the packet = format.
>
>
>
> IANA L2 = scenario:
>
> 2 code point requests for L2 for next header = IPv6 and ICMP
>
>
>
> Zzh6> I don=E2=80=99t = follow what you=E2=80=99re talking about. If BIER header follows
> = Zzh6> L2
> header directly, no new code point is needed. = It=E2=80=99s just =E2=80=9CEthernet
> 0xAB37 | BIER | = payload=E2=80=9D.
>
>
>
>    =  Gyan6> Agreed.
>
>
>
> IANA optional = IPv6 scenario:
>
> 1 code point request for IPv6 for next = header BIER
>
>
>
> Zzh6> If IPv6 = encapsulation is used, either on between directly
> Zzh6> = connected
> BFRs or indirectly connected BFRs, a new =E2=80=9Cnext = header=E2=80=9D code point is
> needed for = BIER.
>
>  Gyan6>Understood
>
>
> = 5
> <https://urldefense.com/v3/__https://nam11.safelinks.pro= tection.outlook.com/?url=3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A= *2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!= NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL= 5sH*24&amp;data=3D04*7C01*7Cmichael.mcbride*40futurewei.com*7C97b8a34= 14dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63= 7420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu= MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=3DnEiVnnCjvgjBOe7= cymYDxS784YHPeOpsWHsatN25kj0*3D&amp;reserved=3D0__;JSUlJSUlJSUlKiUlJS= UlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_Kss= pK1DsMPGcaKe-PHwxls5N$ >.
> IANA = Considerations
>
>
>
>
>
>  =   IANA is requested to assign a new "BIER" type for = "Next Header" in
>
>    the = "Assigned Internet Protocol Numbers" = registry.
>
>
>
>    IANA is requested = to assign a new "BIERin6" type for = "invalid
>
>    options" in the = "ICMP code value" = registry.
>
>
>
>    IANA is requested = to assign a new "BIER IPv6 transportation
> = Sub-sub-
>
>    TLV" type in the "OSPFv3 = BIER Ethernet Encapsulation sub-TLV"
>
>    = Registry.
>
>
>
>    IANA is requested = to set up a new "BIER IPv6 transportation
> = Sub-sub-
>
>    sub-TLV" type in the = "IS-IS BIER Ethernet Encapsulation = sub-sub-TLV"
>
>    = Registry.
>
>
>
>
>
> My point is = that the IANA allocation is different as the next header
> is = different for the L2 scenario where next header is IPv6 or = ICMPV6,
> and IPv6 encapsulation scenario where the next header is = BIER.
>
>
>
> Zzh6> If BIER header follows L2 = header directly, BIER Ethertype is
> Zzh6> used
> = (assuming Ethernet is the L2).
>
>  = Gyan>Understood
>
> Based on this point I am making could = we just do a RFC8296 bis version
> and add the IANA code points = for IPv6 and ICMPv6.
>
>
>
> Zzh6> Given the = confusion/contention that have happened in the last
> Zzh6> = two
> years, it is much better to specifically have a spec = dedicated to
> supporting BIER in IPv6.
>
>  = Gyan6> I think now looking at it holistically speaking I can now = see
> parity between the L2/tunnel and L3/tunnel both also having = the clean
> layering.  So I can see why adding existing = L2/tunnel to BIERin6 even
> though it already exists made sense to = bundle into BIERin6 total
> solution

Juniper Business Use = Only
_______________________________________________
BIER mailing = list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier

_= ______________________________________________
BIER mailing = list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier

------=_NextPart_000_05A5_01D6C8F6.EF080AC0-- From nobody Wed Dec 2 19:24:35 2020 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C843A0962; Wed, 2 Dec 2020 19:24:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bier@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: bier@ietf.org Message-ID: <160696587346.24631.3398114659294338509@ietfa.amsl.com> Date: Wed, 02 Dec 2020 19:24:33 -0800 Archived-At: Subject: [Bier] I-D Action: draft-ietf-bier-lsr-ethernet-extensions-02.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 03:24:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF. Title : LSR Extensions for BIER over Ethernet Authors : Senthil Dhanaraj Gang Yan IJsbrand Wijnands Peter Psenak Zhaohui Zhang Jingrong Xie Filename : draft-ietf-bier-lsr-ethernet-extensions-02.txt Pages : 13 Date : 2020-11-30 Abstract: Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. This document specifies the required extensions to the IS-IS, OSPFv2 and OSPFv3 protocols for supporting BIER in non-MPLS networks using BIER in Ethernet encapsulation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bier-lsr-ethernet-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bier-lsr-ethernet-extensions-02 https://datatracker.ietf.org/doc/html/draft-ietf-bier-lsr-ethernet-extensions-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-lsr-ethernet-extensions-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 2 20:31:36 2020 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0B3A0AB8; Wed, 2 Dec 2020 20:31:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bier@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: bier@ietf.org Message-ID: <160696989046.8628.11670023723472491529@ietfa.amsl.com> Date: Wed, 02 Dec 2020 20:31:30 -0800 Archived-At: Subject: [Bier] I-D Action: draft-ietf-bier-evpn-04.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 04:31:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF. Title : EVPN BUM Using BIER Authors : Zhaohui Zhang Antoni Przygienda Ali Sajassi Jorge Rabadan Filename : draft-ietf-bier-evpn-04.txt Pages : 14 Date : 2020-12-02 Abstract: This document specifies protocols and procedures for forwarding broadcast, unknown unicast and multicast (BUM) traffic of Ethernet VPNs (EVPN) using Bit Index Explicit Replication (BIER). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bier-evpn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bier-evpn-04 https://datatracker.ietf.org/doc/html/draft-ietf-bier-evpn-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-evpn-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 2 23:25:52 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D9C3A08AB for ; Wed, 2 Dec 2020 23:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SPBr7V53deH9 for ; Wed, 2 Dec 2020 23:25:46 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2638E3A08D6 for ; Wed, 2 Dec 2020 23:25:29 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id x15so659734pll.2 for ; Wed, 02 Dec 2020 23:25:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fmkew8na7FxF7RMi1+ZiSGbczkjBTrQx4MbK4V0mO5A=; b=qXh0JpZ8iMF7mhiBvmUUJzICHq7MauD8SZeSU1gSud5GlSp4MaLgop/PEd4a2hYXW+ bYWCRTDWYftN7G4VXphkgXp4bXEItTDAZnxoeZetgzSfCGi0M1aY9Yex+bHU9C0/x/D6 zGYhX1vcW9LHFjYznWdMplsDGdOBiEjY9LXrKTKrVe18xscefzniB0iG8A09J6bN6WGQ u4Fhd0mgNKGbKUyvnqFOXUmpMFtjS7GQ9lZQdr6k2CY/qIF6Oux6bcDZJpxRYcRbU7Sy bpdioGhaqHXVH02OzntTgAIc1HsqZSJPSxpUUVYgRFaUhCIrZUzruSwtKWBQwzhOZmIG sNwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fmkew8na7FxF7RMi1+ZiSGbczkjBTrQx4MbK4V0mO5A=; b=cWVqVAb65hweJylAvT73sO/fn5pYg29rc+EpJKbJ3VnCRsCh5OHX6Geqrcn6gCM3r6 SYblg/9n3RLUzcrSMM8zM9sx4O2MbH8R0qpkfFLZi8R5C4Lw9OV44av7r42NLRijPLkC pos6dWCM4xI/JfpvYYOZkayEQaOGwG4Za/TgzsIFA7atuCNQlpH5mWc8pKUmXxmPTVP+ 5u9EvdNKyCzqmtzPbuZRaYLGZCISU+88l7erB7dwciGED38Qr8PXOUv8794j5EMuIO/O Y7uf+NzSNtRui7UGrlI9D0vZDJv4y5DnlY0racKpB/WjBB0/sSEi4Fz1yXsOy4crdKws ZZLg== X-Gm-Message-State: AOAM532xQJhR1JY3VSqeqUD/fHs5MFqKHluj1asNnAcD5tt8v+GmFZvr 3Q+GG1sNIICzl6Rn5x/voWqNpCMiJbNqPxNnMgk= X-Google-Smtp-Source: ABdhPJyCA5TyWMCaPMooEek2RTwlGbJaYqrL+F5fFfh8K6qcxXhRgy83X+DxXvDcBOmZ+GZx2dPF9hWovQfb7jIQ4eA= X-Received: by 2002:a17:90a:178b:: with SMTP id q11mr1844955pja.132.1606980328515; Wed, 02 Dec 2020 23:25:28 -0800 (PST) MIME-Version: 1.0 References: <00b201d6c70b$0618bae0$124a30a0$@olddog.co.uk> In-Reply-To: From: Gyan Mishra Date: Thu, 3 Dec 2020 02:25:17 -0500 Message-ID: To: Greg Mirsky Cc: Adrian Farrel , BIER WG , "Jeffrey (Zhaohui) Zhang" Content-Type: multipart/alternative; boundary="000000000000a46cb605b58a4309" Archived-At: Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 07:25:51 -0000 --000000000000a46cb605b58a4309 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 2, 2020 at 4:29 PM Greg Mirsky wrote: > Hi Adrian, > you've said: > > This deployment case is somewhat niche: multicast is a bit rare, BIER is > not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, > bridging over IPv6 is a subset of BIER. > > I've paused on the second sentence. As I understand it, BIER is designed > specifically for multicast. Perhaps it is not yet as widely deployed > comparing to the overall multicast deployments but I cannot name what els= e > would benefit from BIER as much as multicast. Is my interpretation close = to > the idea of that sentence? > Good catch! Sorry I glanced over missed it! > > > Regards, > Greg > > On Mon, Nov 30, 2020 at 3:22 AM Adrian Farrel wrote= : > >> Hey Jeffrey, >> >> It may be because I'm late to the discussion, but when you say... >> >> > With the above, there is simply no need for another solution in my vie= w. >> >> ...this seems to suggest that there is already a solution. >> AFAICS, while you might support only one of the two solutions, there are >> two solutions. Neither has been adopted and neither has been "selected". >> >> You might have better phrased this as "this is simply no need for two >> solutions." It might be true that most people agree with that, but since >> they will only agree if their preferred solution is chosen, it is possib= ly >> not very helpful. >> >> However, you go on... >> >> > Of course the WG can continue discussing BIERv6 and may determine that >> it is >> > nice to have BIERv6 as well, but we should not bundle them together >> when it >> > comes to adoption. >> >> ...which seems to suggest that you don't think it is harmful to discuss >> two solutions. >> Since the adoption of one on its own is likely to reduce the chances of >> adoption of the other, not bundling the adoptions might be a little >> simplistic. I am not proposing that we poll the adoption of either solut= ion >> first. Nor am I suggesting making it an either/or adoption poll. >> >> So how about this? >> >> - BIER has a history of starting with Experimental work and seeing how i= t >> develops >> - This deployment case is somewhat niche: multicast is a bit rare, BIER >> is not widely deployed for multicast, IPv6 is still (sadly) not ubiquito= us, >> bridging over IPv6 is a subset of BIER. >> - Why not adopt both approaches as Experimental and set some clear terms >> for the experiment? >> >> Cheers, >> Adrian >> >> -----Original Message----- >> From: BIER On Behalf Of Jeffrey (Zhaohui) Zhang >> Sent: 28 November 2020 21:54 >> To: Michael McBride ; gjshep@gmail.com >> Cc: BIER WG ; Gyan Mishra ; >> draft-ietf-bier-ipv6-requirements < >> draft-ietf-bier-ipv6-requirements@ietf.org>; EXT-zhang.zheng@zte.com.cn = < >> zhang.zheng@zte.com.cn>; Alvaro Retana >> Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 >> >> To clarify, there is no gap in the BIERin6 solution (besides the new >> "next header" code point). It's just that some text are needed to explai= n >> how the requirements are met with the BIERin6 solution - whether it is a >> requirement already listed in the current requirements draft, or have be= en >> brought up in recent mailing list discussions (I know of two in recent >> discussions). >> >> BIERin6 is based on RFC 8296 (plus the new "next header" code point for >> IPv6 encapsulation), and is a generic solution with the following >> properties: >> >> 1. clean layering - BIER over L2/tunnel and it can carry different >> payload types including SRv6 >> 2. IPv4/IPv6 independent (of course you need different signaling) >> 3. L2 independent - as long as the L2 header can indicate with a code >> point that a BIER header follows >> 4. tunnel type independent - as long as the tunnel header can indicate >> with a code point that a BIER header follows >> 5. can work one-hop or multi-hop tunnels nicely >> 6. can work with SRv6 based services nicely >> >> With the above, there is simply no need for another solution in my view. >> Of course the WG can continue discussing BIERv6 and may determine that i= t >> is nice to have BIERv6 as well, but we should not bundle them together w= hen >> it comes to adoption. That's why I suggested in the last BIER session th= e >> following: >> >> - Adopt BIERin6 >> - Discuss BIERv6 further >> >> Jeffrey >> >> -----Original Message----- >> From: Michael McBride >> Sent: Saturday, November 28, 2020 2:15 PM >> To: gjshep@gmail.com; Jeffrey (Zhaohui) Zhang >> Cc: Gyan Mishra ; Alvaro Retana < >> aretana.ietf@gmail.com>; BIER WG ; >> EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < >> tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < >> draft-ietf-bier-ipv6-requirements@ietf.org> >> Subject: RE: draft-ietf-bier-ipv6-requirements-09 >> >> [External Email. Be cautious of content] >> >> >> Hi Greg, >> >> >Thank you Jeffrey and Gyan for sticking with the thread of the >> conversation to advance the discussion. It's clear now that all of the >> requirements >discussed so far can be addressed by the BIERin6 draft if = we >> flesh out the discussed gaps. >> >> >I would like to see Jeffrey and Gyan take over as primary authors of >> >BIERin6 to include the gaps discussed here so that it fully encompases >> the requirements so far described, for WG adoption. >> >> I'm sure I'm misinterpreting. What it sounds like you are saying is "I >> want bierin6 to be adopted so let's fix the gaps so we can begin". Since >> both solutions meet the requirements, I'm hoping you meant "Let's fix th= e >> gaps in bierin6 so we can begin adoption calls for both bierv6 and bieri= n6". >> >> mike >> >> >> On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang < >> zzhang@juniper.net> >> wrote: >> >> > Hi Gyan, >> > >> > >> > >> > Great that we reached consensus on BIERin6. >> > >> > Now there are two lingering points alluded to in this thread, but >> > given it=E2=80=99s been such a long and deeply nested tread, I=E2=80= =99ll start a new >> > thread about it. >> > >> > >> > >> > Thanks. >> > >> > Jeffrey >> > >> > >> > >> > *From:* Gyan Mishra >> > *Sent:* Monday, November 23, 2020 1:32 AM >> > *To:* Jeffrey (Zhaohui) Zhang >> > *Cc:* Alvaro Retana ; BIER WG ; >> > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < >> > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < >> > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com >> > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 >> > >> > >> > >> > *[External Email. Be cautious of content]* >> > >> > >> > >> > Hi Jeffrey >> > >> > >> > >> > That=E2=80=99s the last of my questions related to BIERin6. >> > >> > >> > >> > I thank you for taking the time to go over the BIERin6 draft in detail= . >> > >> > >> > >> > We have reached consensus as well as are in sync, and I now have a >> > better understanding of BIERin6. >> > >> > >> > >> > During the discussions I did mention that maybe in BIERin6 optional >> > IPv6 tunneling should be removed, as it seemed to create some >> > confusion, but now I am clear and as both the L2/tunnel and IPv6 >> > L3/tunnel encapsulation single hop or multi hop tunnel both have the >> > clean BIER layering and complement each other I agree they belong >> together in the same draft. >> > >> > Even though L2/tunnel exists today as part of RFC8296 it makes sense >> > to be part of the overall BIERin6 solution. >> > >> > >> > >> > I am clear on the two IANA code points requests required for the >> > optional >> > IPV6 encapsulation option. >> > >> > >> > >> > Over the course of this thread we did touch on some technical reasons >> > why >> > IPV6 encapsulation is necessary which I you mentioned in some of your >> > responses. >> > >> > >> > >> > Overall throughout the discussions I agree that BIERin6 IPV6 tunnel >> > option and BIERv6 are not transitional and are long term solutions and >> > there are reasons why that we can add to the requirements draft as to >> > why IPV6 encapsulation is necessary below: >> > >> > >> > >> > - Operator requirement for IPV6 encapsulated packets and not L2 >> > encapsulation. >> > >> > -FRR >> > >> > >> > >> > I think we are all set to start updating the Requirements draft. >> > >> > >> > >> > In-line Gyan6> >> > >> > >> > >> > Kind Regards >> > >> > >> > >> > Gyan >> > >> > >> > >> > On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang < >> > zzhang@juniper.net> wrote: >> > >> > Gyan, >> > >> > >> > >> > Please see zzh6> below. >> > >> > >> > >> > *From:* Gyan Mishra >> > *Sent:* Sunday, November 22, 2020 9:49 PM >> > *To:* Jeffrey (Zhaohui) Zhang >> > *Cc:* Alvaro Retana ; BIER WG ; >> > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < >> > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < >> > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com >> > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 >> > >> > >> > >> > *[External Email. Be cautious of content]* >> > >> > >> > >> > >> > >> > Hi Jeffrey >> > >> > >> > >> > Agreed we have reached a consensus. >> > >> > >> > >> > >> > >> > Few more questions to iron out understanding. >> > >> > >> > >> > In line gyan4> >> > >> > >> > >> > Zzh6> Apparently there are still disconnects =F0=9F=98=8A >> > >> > Gyan> Thank you for all the detailed responses. We are in sync now! >> > >> > On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang < >> > zzhang@juniper.net> wrote: >> > >> > Hi Gyan, >> > >> > >> > >> > Yes I believe we=E2=80=99ve reached consensus. >> > >> > >> > >> > Please see zzh5> below about some details. >> > >> > >> > >> > *From:* Gyan Mishra >> > *Sent:* Sunday, November 22, 2020 4:19 PM >> > *To:* Jeffrey (Zhaohui) Zhang >> > *Cc:* Alvaro Retana ; BIER WG ; >> > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < >> > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < >> > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com >> > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 >> > >> > >> > >> > *[External Email. Be cautious of content]* >> > >> > >> > >> > Hi Jeffrey >> > >> > >> > >> > This has been a very informative exchange and extremely helpful for >> > all of us to get onto the same page from a basic understanding POV. >> > >> > >> > >> > Much appreciated all your help and feedback helping clarify my >> confusion. >> > >> > >> > >> > I am answering in-line but now connecting the dots how is in today=E2= =80=99s >> > RFC >> > 8296 Non MPLS BIER Ethernet going to transport IPv6? >> > >> > >> > >> > From your answers below it cannot work as we need two IANA code point >> > one for IPv6 next header type and ICMPv6. >> > >> > >> > >> > Zzh5> The existing model/concept works except that we need to two code >> > points if IPv6 tunneling is used for either getting over non-BFRs or >> > for FRR. One may deem non-BFR as a short-term scenario but FRR will be >> > here for the long run. >> > >> > >> > >> > Gyan4>I am a little confused here with the code points. For >> > BIERin6 =E2=80=9CL2=E2=80=9D BIER scenario RFC 8296 Non MPLS BIER Ethe= rnet Ether type >> 0xAB37. >> > >> > >> > >> > Ethernet -0xAB37 l BIER | IPv6 | payload >> > >> > >> > >> > Zzh6> Note that IPv6 header is not needed =E2=80=93 it should be Ether= net >> > Zzh6> -0xAB37 >> > l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6 >> > header may be inserted between BIER and payload, only for the SRv6 >> > style VPN purpose. >> > >> > Gyan> Understood >> > >> > Ethernet -0xAB37 l BIER l ICMPv6 | payload >> > >> > >> > >> > Zzh6> ICMP was mentioned not for encapsulation but for the following: >> > >> > Gyan6>Understood >> > >> > Zzh6> 2.1. IPv6 Options Considerations >> > >> > >> > >> > For directly connected BIER routers, IPv6 Hop-by-Hop or Destination >> > >> > options are irrelevant and SHOULD NOT be inserted by BFIR on the >> > >> > BIERin6 packet. In this case IPv6 header, Next Header field should >> > >> > be set to TBD. Any IPv6 packet arriving on BFRs and BFERs, with >> > >> > multiple extension header where the last extension header has a >> > Next >> > >> > Header field set to TBD, SHOULD be discard and the node should >> > >> > transmit an ICMP Parameter Problem message to the source of the >> > >> > packet (BFIR) with an ICMP code value of TBD10 ('invalid options >> > for >> > >> > BIERin6'). >> > >> > >> > >> > In this particular scenario where adjacent BFRs support Ethernet link >> > layer in an IPV6 environment and IPv6 or ICMPv6 encapsulation and the >> > need for the next header code point above is the packet format: >> > >> > >> > >> > Excerpt from RFC 8296 >> > >> > >> > >> > Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet >> > >> > header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332 >> > > > k.com/?url=3Dhttps*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Ce= tp >> > u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$ >> > defense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!! >> > NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8 >> > 4ssHlj%24&data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7C97b8a= 34 >> > 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7 >> > C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj >> > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D8EiHsMns5J= ut >> > 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&reserved=3D0>]. IEEE >> > >> > has assigned Ethertype 0xAB37 for non-MPLS BIER packets. >> > >> > >> > >> > >> > >> > In the case of BIERin6 optional encapsulation option, in case where >> > operators requires packets forwarded in IPv6 or tunneling over Non BFR >> > packet format below: >> > >> > >> > >> > IPv6 outer header l BIER l Data >> > >> > >> > >> > So here the next header is BIER so corresponding next header code poin= t. >> > >> > >> > >> > >> > >> > So below is for both cases IANA code point allocation for =E2=80=9CL2= =E2=80=9D next >> > header where next header is IPv6 or ICMPV6, and then the optional IPv6 >> > encapsulation option where the next header is BIER. >> > >> > >> > >> > Would those be two separate IANA code point requests I what I see from >> > the packet format. >> > >> > >> > >> > IANA L2 scenario: >> > >> > 2 code point requests for L2 for next header IPv6 and ICMP >> > >> > >> > >> > Zzh6> I don=E2=80=99t follow what you=E2=80=99re talking about. If BIE= R header follows >> > Zzh6> L2 >> > header directly, no new code point is needed. It=E2=80=99s just =E2=80= =9CEthernet >> > 0xAB37 | BIER | payload=E2=80=9D. >> > >> > >> > >> > Gyan6> Agreed. >> > >> > >> > >> > IANA optional IPv6 scenario: >> > >> > 1 code point request for IPv6 for next header BIER >> > >> > >> > >> > Zzh6> If IPv6 encapsulation is used, either on between directly >> > Zzh6> connected >> > BFRs or indirectly connected BFRs, a new =E2=80=9Cnext header=E2=80=9D= code point is >> > needed for BIER. >> > >> > Gyan6>Understood >> > >> > >> > 5 >> > < >> https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.c= om/?url=3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2= Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fp= nhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24&data=3D04*7C= 01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7C0= fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7CTW= FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3= D*7C1000&sdata=3DnEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&res= erved=3D0__;JSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueS= P2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N$ >> >. >> > IANA Considerations >> > >> > >> > >> > >> > >> > IANA is requested to assign a new "BIER" type for "Next Header" in >> > >> > the "Assigned Internet Protocol Numbers" registry. >> > >> > >> > >> > IANA is requested to assign a new "BIERin6" type for "invalid >> > >> > options" in the "ICMP code value" registry. >> > >> > >> > >> > IANA is requested to assign a new "BIER IPv6 transportation >> > Sub-sub- >> > >> > TLV" type in the "OSPFv3 BIER Ethernet Encapsulation sub-TLV" >> > >> > Registry. >> > >> > >> > >> > IANA is requested to set up a new "BIER IPv6 transportation >> > Sub-sub- >> > >> > sub-TLV" type in the "IS-IS BIER Ethernet Encapsulation sub-sub-TLV= " >> > >> > Registry. >> > >> > >> > >> > >> > >> > My point is that the IANA allocation is different as the next header >> > is different for the L2 scenario where next header is IPv6 or ICMPV6, >> > and IPv6 encapsulation scenario where the next header is BIER. >> > >> > >> > >> > Zzh6> If BIER header follows L2 header directly, BIER Ethertype is >> > Zzh6> used >> > (assuming Ethernet is the L2). >> > >> > Gyan>Understood >> > >> > Based on this point I am making could we just do a RFC8296 bis version >> > and add the IANA code points for IPv6 and ICMPv6. >> > >> > >> > >> > Zzh6> Given the confusion/contention that have happened in the last >> > Zzh6> two >> > years, it is much better to specifically have a spec dedicated to >> > supporting BIER in IPv6. >> > >> > Gyan6> I think now looking at it holistically speaking I can now see >> > parity between the L2/tunnel and L3/tunnel both also having the clean >> > layering. So I can see why adding existing L2/tunnel to BIERin6 even >> > though it already exists made sense to bundle into BIERin6 total >> > solution >> >> Juniper Business Use Only >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier >> > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000a46cb605b58a4309 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 2, 2020 at 4:29 PM Greg Mirsky <<= a href=3D"mailto:gregimirsky@gmail.com">gregimirsky@gmail.com> wrote= :
Hi Adrian,
y= ou've said:
This deployment case is somewhat niche: multicast is a = bit rare, BIER is not widely deployed for multicast, IPv6 is still (sadly) = not ubiquitous, bridging over IPv6 is a subset of BIER.=C2=A0
I've paused on the second sentence. As I understand it, BIER is de= signed specifically for multicast. Perhaps it is not yet as widely deployed= comparing to the overall multicast deployments but I cannot name what else= would benefit from BIER as much as multicast. Is my interpretation close t= o the idea of that sentence?

=
=C2=A0 =C2=A0Good catch!=C2=A0 Sorry I glanced over= missed it!


Regards,
Greg
=
On Mon= , Nov 30, 2020 at 3:22 AM Adrian Farrel <adrian@olddog.co.uk> wrote:
Hey Jeffrey,

It may be because I'm late to the discussion, but when you say...

> With the above, there is simply no need for another solution in my vie= w.

...this seems to suggest that there is already a solution.
AFAICS, while you might support only one of the two solutions, there are tw= o solutions. Neither has been adopted and neither has been "selected&q= uot;.

You might have better phrased this as "this is simply no need for two = solutions." It might be true that most people agree with that, but sin= ce they will only agree if their preferred solution is chosen, it is possib= ly not very helpful.

However, you go on...

> Of course the WG can continue discussing BIERv6 and may determine that= it is
> nice to have BIERv6 as well, but we should not bundle them together wh= en it
> comes to adoption.

...which seems to suggest that you don't think it is harmful to discuss= two solutions.
Since the adoption of one on its own is likely to reduce the chances of ado= ption of the other, not bundling the adoptions might be a little simplistic= . I am not proposing that we poll the adoption of either solution first. No= r am I suggesting making it an either/or adoption poll.

So how about this?

- BIER has a history of starting with Experimental work and seeing how it d= evelops
- This deployment case is somewhat niche: multicast is a bit rare, BIER is = not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, br= idging over IPv6 is a subset of BIER.
- Why not adopt both approaches as Experimental and set some clear terms fo= r the experiment?

Cheers,
Adrian

-----Original Message-----
From: BIER <b= ier-bounces@ietf.org> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 28 November 2020 21:54
To: Michael McBride <michael.mcbride@futurewei.com>; gjshep@gmail.com
Cc: BIER WG <bier@iet= f.org>; Gyan Mishra <hayabusagsm@gmail.com>; draft-ietf-bier-ipv6-requirem= ents <draft-ietf-bier-ipv6-requirements@ietf.org>; EXT-zhang.zheng@zt= e.com.cn <zhang.zheng@zte.com.cn>; Alvaro Retana <aretana.ietf@gmail.com>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

To clarify, there is no gap in the BIERin6 solution (besides the new "= next header" code point). It's just that some text are needed to e= xplain how the requirements are met with the BIERin6 solution - whether it = is a requirement already listed in the current requirements draft, or have = been brought up in recent mailing list discussions (I know of two in recent= discussions).

BIERin6 is based on RFC 8296 (plus the new "next header" code poi= nt for IPv6 encapsulation), and is a generic solution with the following pr= operties:

1. clean layering - BIER over L2/tunnel and it can carry different payload = types including SRv6
2. IPv4/IPv6 independent (of course you need different signaling)
3. L2 independent - as long as the L2 header can indicate with a code point= that a BIER header follows
4. tunnel type independent - as long as the tunnel header can indicate with= a code point that a BIER header follows
5. can work one-hop or multi-hop tunnels nicely
6. can work with SRv6 based services nicely

With the above, there is simply no need for another solution in my view. Of= course the WG can continue discussing BIERv6 and may determine that it is = nice to have BIERv6 as well, but we should not bundle them together when it= comes to adoption. That's why I suggested in the last BIER session the= following:

- Adopt BIERin6
- Discuss BIERv6 further

Jeffrey

-----Original Message-----
From: Michael McBride <michael.mcbride@futurewei.com>
Sent: Saturday, November 28, 2020 2:15 PM
To: gjshep@gmail.com<= /a>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Alvaro Retana <aretana.ietf@gmail.com>; BIER = WG <bier@ietf.org= >; EXT-z= hang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <tonysietf@gmail.com&g= t;; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-require= ments@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]


Hi Greg,

>Thank you Jeffrey and Gyan for sticking with the thread of the conversa= tion to advance the discussion. It's clear now that all of the requirem= ents >discussed so far can be addressed by the BIERin6 draft if we flesh= out the discussed gaps.

>I would like to see Jeffrey and Gyan take over as primary authors of >BIERin6 to include the gaps discussed here so that it fully encompases = the requirements so far described, for WG adoption.

I'm sure I'm misinterpreting. What it sounds like you are saying is= "I want bierin6 to be adopted so let's fix the gaps so we can beg= in". Since both solutions meet the requirements, I'm hoping you me= ant "Let's fix the gaps in bierin6 so we can begin adoption calls = for both bierv6 and bierin6".

mike


On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Hi Gyan,
>
>
>
> Great that we reached consensus on BIERin6.
>
> Now there are two lingering points alluded to in this thread, but
> given it=E2=80=99s been such a long and deeply nested tread, I=E2=80= =99ll start a new
> thread about it.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Monday, November 23, 2020 1:32 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> That=E2=80=99s the last of my questions related to BIERin6.
>
>
>
> I thank you for taking the time to go over the BIERin6 draft in detail= .
>
>
>
> We have reached consensus as well as are in sync,=C2=A0 and I now have= a
> better understanding of BIERin6.
>
>
>
> During the discussions I did mention that maybe in BIERin6 optional > IPv6 tunneling should be removed, as it seemed to create some
> confusion, but now I am clear and as both the L2/tunnel and IPv6
> L3/tunnel encapsulation single hop or multi hop tunnel both have the > clean BIER layering and complement each other I agree they belong toge= ther in the same draft.
>
> Even though L2/tunnel exists today as part of RFC8296 it makes sense > to be part of the overall BIERin6 solution.
>
>
>
> I am clear on the two IANA code points requests required for the
> optional
> IPV6 encapsulation option.
>
>
>
> Over the course of this thread we did touch on some technical reasons<= br> > why
> IPV6 encapsulation is necessary which I you mentioned in some of your<= br> > responses.
>
>
>
> Overall throughout the discussions I agree that BIERin6 IPV6 tunnel > option and BIERv6 are not transitional and are long term solutions and=
> there are reasons why that we can add to the requirements draft as to<= br> > why IPV6 encapsulation is necessary below:
>
>
>
> - Operator requirement for IPV6 encapsulated packets=C2=A0 and not L2<= br> > encapsulation.
>
> -FRR
>
>
>
> I think we are all set to start updating the Requirements draft.
>
>
>
> In-line Gyan6>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper= .net> wrote:
>
> Gyan,
>
>
>
> Please see zzh6> below.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 9:49 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Agreed we have reached a consensus.
>
>
>
>
>
> Few more questions to iron out understanding.
>
>
>
> In line gyan4>
>
>
>
> Zzh6> Apparently there are still disconnects =F0=9F=98=8A
>
>=C2=A0 Gyan> Thank you for all the detailed responses.=C2=A0 We are = in sync now!
>
> On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper= .net> wrote:
>
> Hi Gyan,
>
>
>
> Yes I believe we=E2=80=99ve reached consensus.
>
>
>
> Please see zzh5> below about some details.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 4:19 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> This has been a very informative exchange and extremely helpful for > all of us to get onto the same page from a basic understanding POV. >
>
>
> Much appreciated all your help and feedback helping clarify my confusi= on.
>
>
>
> I am answering in-line but now connecting the dots how is in today=E2= =80=99s
> RFC
> 8296 Non MPLS BIER Ethernet going to transport IPv6?
>
>
>
> From your answers below it cannot work as we need two IANA code point<= br> > one for IPv6 next header type and ICMPv6.
>
>
>
> Zzh5> The existing model/concept works except that we need to two c= ode
> points if IPv6 tunneling is used for either getting over non-BFRs or > for FRR. One may deem non-BFR as a short-term scenario but FRR will be=
> here for the long run.
>
>
>
>=C2=A0 =C2=A0 =C2=A0Gyan4>I am a little confused here with the code = points.=C2=A0 For
> BIERin6 =E2=80=9CL2=E2=80=9D BIER scenario RFC 8296 Non MPLS BIER Ethe= rnet Ether type 0xAB37.
>
>
>
> Ethernet -0xAB37 l BIER | IPv6 | payload
>
>
>
> Zzh6> Note that IPv6 header is not needed =E2=80=93 it should be Et= hernet
> Zzh6> -0xAB37
> l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6=
> header may be inserted between BIER and payload, only for the SRv6
> style VPN purpose.
>
> Gyan> Understood
>
> Ethernet -0xAB37 l BIER l ICMPv6 | payload
>
>
>
> Zzh6> ICMP was mentioned not for encapsulation but for the followin= g:
>
>=C2=A0 Gyan6>Understood
>
> Zzh6> 2.1.=C2=A0 IPv6 Options Considerations
>
>
>
>=C2=A0 =C2=A0 For directly connected BIER routers, IPv6 Hop-by-Hop or D= estination
>
>=C2=A0 =C2=A0 options are irrelevant and SHOULD NOT be inserted by BFIR= on the
>
>=C2=A0 =C2=A0 BIERin6 packet.=C2=A0 In this case IPv6 header, Next Head= er field should
>
>=C2=A0 =C2=A0 be set to TBD.=C2=A0 Any IPv6 packet arriving on BFRs and= BFERs, with
>
>=C2=A0 =C2=A0 multiple extension header where the last extension header= has a
> Next
>
>=C2=A0 =C2=A0 Header field set to TBD, SHOULD be discard and the node s= hould
>
>=C2=A0 =C2=A0 transmit an ICMP Parameter Problem message to the source = of the
>
>=C2=A0 =C2=A0 packet (BFIR) with an ICMP code value of TBD10 ('inva= lid options
> for
>
>=C2=A0 =C2=A0 BIERin6').
>
>
>
> In this particular scenario where adjacent BFRs support Ethernet link<= br> > layer in an IPV6 environment and=C2=A0 IPv6 or ICMPv6 encapsulation an= d the
> need for the next header code point above is the packet format:
>
>
>
> Excerpt from RFC 8296
>
>
>
>=C2=A0 =C2=A0 Therefore, if a non-MPLS BIER packet is encapsulated in a= n Ethernet
>
>=C2=A0 =C2=A0 header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC53= 32
> <https://urldefense.com= /v3/__https://nam11.safelinks.protection.outloo
> k.com/?url=3Dhtt= ps*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp
> u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$
> de= fense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!!<= br> > NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8=
> 4ssHlj%24&amp;data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7C= 97b8a34
> 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7=
> C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj=
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D8EiHsM= ns5Jut
> 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&amp;reserved=3D0>].=C2=A0 IE= EE
>
>=C2=A0 =C2=A0 has assigned Ethertype 0xAB37 for non-MPLS BIER packets.<= br> >
>
>
>
>
> In the case of BIERin6 optional encapsulation option, in case where > operators requires packets forwarded in IPv6 or tunneling over Non BFR=
> packet format below:
>
>
>
> IPv6 outer header l BIER l Data
>
>
>
> So here the next header is BIER so corresponding next header code poin= t.
>
>
>
>
>
> So below is for both cases IANA code point allocation for =E2=80=9CL2= =E2=80=9D next
> header where next header is IPv6 or ICMPV6, and then the optional IPv6=
> encapsulation option where the next header is BIER.
>
>
>
> Would those be two separate IANA code point requests I what I see from=
> the packet format.
>
>
>
> IANA L2 scenario:
>
> 2 code point requests for L2 for next header IPv6 and ICMP
>
>
>
> Zzh6> I don=E2=80=99t follow what you=E2=80=99re talking about. If = BIER header follows
> Zzh6> L2
> header directly, no new code point is needed. It=E2=80=99s just =E2=80= =9CEthernet
> 0xAB37 | BIER | payload=E2=80=9D.
>
>
>
>=C2=A0 =C2=A0 =C2=A0Gyan6> Agreed.
>
>
>
> IANA optional IPv6 scenario:
>
> 1 code point request for IPv6 for next header BIER
>
>
>
> Zzh6> If IPv6 encapsulation is used, either on between directly
> Zzh6> connected
> BFRs or indirectly connected BFRs, a new =E2=80=9Cnext header=E2=80=9D= code point is
> needed for BIER.
>
>=C2=A0 Gyan6>Understood
>
>
> 5
> <https://urldefense.com/v3/__http= s://nam11.safelinks.protection.outlook.com/?url=3Dhttps*3A*2F*2Furldefense.= com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07= *section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR= 14p1w2ObtXPqQ_dVL5sH*24&amp;data=3D04*7C01*7Cmichael.mcbride*40futurewe= i.com*7C97b8a3414dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc= *7C1*7C0*7C637420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL= CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=3DnEiVnn= CjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&amp;reserved=3D0__;JSUlJSUlJSU= lKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7= s_KsspK1DsMPGcaKe-PHwxls5N$ >.
> IANA Considerations
>
>
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIER" type f= or "Next Header" in
>
>=C2=A0 =C2=A0 the "Assigned Internet Protocol Numbers" regist= ry.
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIERin6" typ= e for "invalid
>
>=C2=A0 =C2=A0 options" in the "ICMP code value" registry= .
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIER IPv6 transpo= rtation
> Sub-sub-
>
>=C2=A0 =C2=A0 TLV" type in the "OSPFv3 BIER Ethernet Encapsul= ation sub-TLV"
>
>=C2=A0 =C2=A0 Registry.
>
>
>
>=C2=A0 =C2=A0 IANA is requested to set up a new "BIER IPv6 transpo= rtation
> Sub-sub-
>
>=C2=A0 =C2=A0 sub-TLV" type in the "IS-IS BIER Ethernet Encap= sulation sub-sub-TLV"
>
>=C2=A0 =C2=A0 Registry.
>
>
>
>
>
> My point is that the IANA allocation is different as the next header > is different for the L2 scenario where next header is IPv6 or ICMPV6,<= br> > and IPv6 encapsulation scenario where the next header is BIER.
>
>
>
> Zzh6> If BIER header follows L2 header directly, BIER Ethertype is<= br> > Zzh6> used
> (assuming Ethernet is the L2).
>
>=C2=A0 Gyan>Understood
>
> Based on this point I am making could we just do a RFC8296 bis version=
> and add the IANA code points for IPv6 and ICMPv6.
>
>
>
> Zzh6> Given the confusion/contention that have happened in the last=
> Zzh6> two
> years, it is much better to specifically have a spec dedicated to
> supporting BIER in IPv6.
>
>=C2=A0 Gyan6> I think now looking at it holistically speaking I can = now see
> parity between the L2/tunnel and L3/tunnel both also having the clean<= br> > layering.=C2=A0 So I can see why adding existing L2/tunnel to BIERin6 = even
> though it already exists made sense to bundle into BIERin6 total
> solution

Juniper Business Use Only
_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier
_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier
--
--000000000000a46cb605b58a4309-- From nobody Wed Dec 2 23:39:01 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D211A3A0A71 for ; Wed, 2 Dec 2020 23:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hzo60DlcP3AN for ; Wed, 2 Dec 2020 23:38:46 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8069B3A0A73 for ; Wed, 2 Dec 2020 23:38:46 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id q22so705581pfk.12 for ; Wed, 02 Dec 2020 23:38:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XQx86Ypm24ISdXUy2r92yDWoiFEq/0wTvTlfd5MhGAc=; b=K+sQKUy7771Vblb43PyTnhFERp9jsFWO8u8wt91ke64tUK9dEgEcHmbIkALAvkJoh5 nk9wAxVsZL61I1oZ2J5xdM+LsKTE2UoUtSRP28ffqVR9ng+2Cb6X0+87OtKl0ch3G8xn r91ZbqQHywHoVbbDUod26xWKpYIDtwejJC1tB8rRfaP59Lu/fs9nUBTwLJdmdx+m5KAg RLQgCXjaPg45QmHktDfpRp5Y/sivt/TB5uiZBf6aVPx5YG/rLgx1M2F2Hm2ghJg0xZC+ qMMcoSD3aXgEgmiCAYFBewYdLDe6CoC+nzszPDl2c/X0zRlz+xJk2XNdzWR1WVPZ6XQD R5XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XQx86Ypm24ISdXUy2r92yDWoiFEq/0wTvTlfd5MhGAc=; b=OI6T+8f4lrP65+Wpp6d9UlFp1ndPJjUJV4052rruW2V5zRYaXoetXYNHYhGiHfW2Ks RVK+TlgCHJNhJMoRfUqGI9Klfk3qqzQ6jDv/cGNpvyeawJnFBl6oUXbM6YMNfE95X7Q7 PqFhCKI9QwLOch5BOk/2K3pcl/0d+9gLcCWJG+J3QtGHc5axW6Ws24M88NkaFwd167yk +uKUOvpMtDyS6mNu68qnJp1lxdIrZMQy+pGZdG9E6TVtl07nq1bBzkDz4zowR0krUXx3 /DEzigKUEOT3OlL6Ifi0XOlovnUPc1adZNX2i+oyIYU/lqyAUmjSxsLtdER5fCCfb/Aq hUtA== X-Gm-Message-State: AOAM531b85PlcyzDzwBsczwZzyZKQyhOwnLLI7z9T792/UyNVLoWkw6B KqoOy76bkeWgrJHx0snxVOQtMvXxtgbmzNB7tfk= X-Google-Smtp-Source: ABdhPJxKMC/uZLCm+cPu+yhIuqvkiDDmxuVAP3ZdCd+0H+c+UIq3QzrQkjfeIw3E//puqOF7MtplYdhHtFWoUVP2jfk= X-Received: by 2002:a62:5543:0:b029:19d:930f:9a17 with SMTP id j64-20020a6255430000b029019d930f9a17mr2158668pfb.20.1606981125823; Wed, 02 Dec 2020 23:38:45 -0800 (PST) MIME-Version: 1.0 References: <00b201d6c70b$0618bae0$124a30a0$@olddog.co.uk> In-Reply-To: From: Gyan Mishra Date: Thu, 3 Dec 2020 02:38:34 -0500 Message-ID: To: Greg Mirsky Cc: Adrian Farrel , BIER WG , "Jeffrey (Zhaohui) Zhang" Content-Type: multipart/alternative; boundary="0000000000002a611705b58a73b8" Archived-At: Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 07:38:59 -0000 --0000000000002a611705b58a73b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 2, 2020 at 4:29 PM Greg Mirsky wrote: > Hi Adrian, > you've said: > > This deployment case is somewhat niche: multicast is a bit rare, BIER is > not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, > bridging over IPv6 is a subset of BIER. > > I've paused on the second sentence. As I understand it, BIER is designed > specifically for multicast. Perhaps it is not yet as widely deployed > comparing to the overall multicast deployments but I cannot name what els= e > would benefit from BIER as much as multicast. Is my interpretation close = to > the idea of that sentence? > My comment on IPv6 not yet ubiquitous. Granted IPv6 is not yet ubiquitous, however as the many benefits to be realized with SRv6, operators are pushing fast to upgrade to RFC 5565 softwire mesh framework v4v6 edge over a v6 only core. As operators shift there core to IPv6 over the next few years BIER x-PMSI MVPN over SRv6 core will soon be ubiquitous and a reality. We are not to far off from a complete paradigm shift from v4 core to ubiquitous v6 core. This will happen much sooner then of course the actual proliferation of IPv6 traffic worldwide which may take a lifetime. Although with 5G and network slicing that in itself will be a paradigm shift and also toward IPv6 only mobile and fixed 5G. > > > Regards, > Greg > > On Mon, Nov 30, 2020 at 3:22 AM Adrian Farrel wrote= : > >> Hey Jeffrey, >> >> It may be because I'm late to the discussion, but when you say... >> >> > With the above, there is simply no need for another solution in my vie= w. >> >> ...this seems to suggest that there is already a solution. >> AFAICS, while you might support only one of the two solutions, there are >> two solutions. Neither has been adopted and neither has been "selected". >> >> You might have better phrased this as "this is simply no need for two >> solutions." It might be true that most people agree with that, but since >> they will only agree if their preferred solution is chosen, it is possib= ly >> not very helpful. >> >> However, you go on... >> >> > Of course the WG can continue discussing BIERv6 and may determine that >> it is >> > nice to have BIERv6 as well, but we should not bundle them together >> when it >> > comes to adoption. >> >> ...which seems to suggest that you don't think it is harmful to discuss >> two solutions. >> Since the adoption of one on its own is likely to reduce the chances of >> adoption of the other, not bundling the adoptions might be a little >> simplistic. I am not proposing that we poll the adoption of either solut= ion >> first. Nor am I suggesting making it an either/or adoption poll. >> >> So how about this? >> >> - BIER has a history of starting with Experimental work and seeing how i= t >> develops >> - This deployment case is somewhat niche: multicast is a bit rare, BIER >> is not widely deployed for multicast, IPv6 is still (sadly) not ubiquito= us, >> bridging over IPv6 is a subset of BIER. >> - Why not adopt both approaches as Experimental and set some clear terms >> for the experiment? >> >> Cheers, >> Adrian >> >> -----Original Message----- >> From: BIER On Behalf Of Jeffrey (Zhaohui) Zhang >> Sent: 28 November 2020 21:54 >> To: Michael McBride ; gjshep@gmail.com >> Cc: BIER WG ; Gyan Mishra ; >> draft-ietf-bier-ipv6-requirements < >> draft-ietf-bier-ipv6-requirements@ietf.org>; EXT-zhang.zheng@zte.com.cn = < >> zhang.zheng@zte.com.cn>; Alvaro Retana >> Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09 >> >> To clarify, there is no gap in the BIERin6 solution (besides the new >> "next header" code point). It's just that some text are needed to explai= n >> how the requirements are met with the BIERin6 solution - whether it is a >> requirement already listed in the current requirements draft, or have be= en >> brought up in recent mailing list discussions (I know of two in recent >> discussions). >> >> BIERin6 is based on RFC 8296 (plus the new "next header" code point for >> IPv6 encapsulation), and is a generic solution with the following >> properties: >> >> 1. clean layering - BIER over L2/tunnel and it can carry different >> payload types including SRv6 >> 2. IPv4/IPv6 independent (of course you need different signaling) >> 3. L2 independent - as long as the L2 header can indicate with a code >> point that a BIER header follows >> 4. tunnel type independent - as long as the tunnel header can indicate >> with a code point that a BIER header follows >> 5. can work one-hop or multi-hop tunnels nicely >> 6. can work with SRv6 based services nicely >> >> With the above, there is simply no need for another solution in my view. >> Of course the WG can continue discussing BIERv6 and may determine that i= t >> is nice to have BIERv6 as well, but we should not bundle them together w= hen >> it comes to adoption. That's why I suggested in the last BIER session th= e >> following: >> >> - Adopt BIERin6 >> - Discuss BIERv6 further >> >> Jeffrey >> >> -----Original Message----- >> From: Michael McBride >> Sent: Saturday, November 28, 2020 2:15 PM >> To: gjshep@gmail.com; Jeffrey (Zhaohui) Zhang >> Cc: Gyan Mishra ; Alvaro Retana < >> aretana.ietf@gmail.com>; BIER WG ; >> EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < >> tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < >> draft-ietf-bier-ipv6-requirements@ietf.org> >> Subject: RE: draft-ietf-bier-ipv6-requirements-09 >> >> [External Email. Be cautious of content] >> >> >> Hi Greg, >> >> >Thank you Jeffrey and Gyan for sticking with the thread of the >> conversation to advance the discussion. It's clear now that all of the >> requirements >discussed so far can be addressed by the BIERin6 draft if = we >> flesh out the discussed gaps. >> >> >I would like to see Jeffrey and Gyan take over as primary authors of >> >BIERin6 to include the gaps discussed here so that it fully encompases >> the requirements so far described, for WG adoption. >> >> I'm sure I'm misinterpreting. What it sounds like you are saying is "I >> want bierin6 to be adopted so let's fix the gaps so we can begin". Since >> both solutions meet the requirements, I'm hoping you meant "Let's fix th= e >> gaps in bierin6 so we can begin adoption calls for both bierv6 and bieri= n6". >> >> mike >> >> >> On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang < >> zzhang@juniper.net> >> wrote: >> >> > Hi Gyan, >> > >> > >> > >> > Great that we reached consensus on BIERin6. >> > >> > Now there are two lingering points alluded to in this thread, but >> > given it=E2=80=99s been such a long and deeply nested tread, I=E2=80= =99ll start a new >> > thread about it. >> > >> > >> > >> > Thanks. >> > >> > Jeffrey >> > >> > >> > >> > *From:* Gyan Mishra >> > *Sent:* Monday, November 23, 2020 1:32 AM >> > *To:* Jeffrey (Zhaohui) Zhang >> > *Cc:* Alvaro Retana ; BIER WG ; >> > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < >> > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < >> > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com >> > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 >> > >> > >> > >> > *[External Email. Be cautious of content]* >> > >> > >> > >> > Hi Jeffrey >> > >> > >> > >> > That=E2=80=99s the last of my questions related to BIERin6. >> > >> > >> > >> > I thank you for taking the time to go over the BIERin6 draft in detail= . >> > >> > >> > >> > We have reached consensus as well as are in sync, and I now have a >> > better understanding of BIERin6. >> > >> > >> > >> > During the discussions I did mention that maybe in BIERin6 optional >> > IPv6 tunneling should be removed, as it seemed to create some >> > confusion, but now I am clear and as both the L2/tunnel and IPv6 >> > L3/tunnel encapsulation single hop or multi hop tunnel both have the >> > clean BIER layering and complement each other I agree they belong >> together in the same draft. >> > >> > Even though L2/tunnel exists today as part of RFC8296 it makes sense >> > to be part of the overall BIERin6 solution. >> > >> > >> > >> > I am clear on the two IANA code points requests required for the >> > optional >> > IPV6 encapsulation option. >> > >> > >> > >> > Over the course of this thread we did touch on some technical reasons >> > why >> > IPV6 encapsulation is necessary which I you mentioned in some of your >> > responses. >> > >> > >> > >> > Overall throughout the discussions I agree that BIERin6 IPV6 tunnel >> > option and BIERv6 are not transitional and are long term solutions and >> > there are reasons why that we can add to the requirements draft as to >> > why IPV6 encapsulation is necessary below: >> > >> > >> > >> > - Operator requirement for IPV6 encapsulated packets and not L2 >> > encapsulation. >> > >> > -FRR >> > >> > >> > >> > I think we are all set to start updating the Requirements draft. >> > >> > >> > >> > In-line Gyan6> >> > >> > >> > >> > Kind Regards >> > >> > >> > >> > Gyan >> > >> > >> > >> > On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang < >> > zzhang@juniper.net> wrote: >> > >> > Gyan, >> > >> > >> > >> > Please see zzh6> below. >> > >> > >> > >> > *From:* Gyan Mishra >> > *Sent:* Sunday, November 22, 2020 9:49 PM >> > *To:* Jeffrey (Zhaohui) Zhang >> > *Cc:* Alvaro Retana ; BIER WG ; >> > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < >> > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < >> > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com >> > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 >> > >> > >> > >> > *[External Email. Be cautious of content]* >> > >> > >> > >> > >> > >> > Hi Jeffrey >> > >> > >> > >> > Agreed we have reached a consensus. >> > >> > >> > >> > >> > >> > Few more questions to iron out understanding. >> > >> > >> > >> > In line gyan4> >> > >> > >> > >> > Zzh6> Apparently there are still disconnects =F0=9F=98=8A >> > >> > Gyan> Thank you for all the detailed responses. We are in sync now! >> > >> > On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang < >> > zzhang@juniper.net> wrote: >> > >> > Hi Gyan, >> > >> > >> > >> > Yes I believe we=E2=80=99ve reached consensus. >> > >> > >> > >> > Please see zzh5> below about some details. >> > >> > >> > >> > *From:* Gyan Mishra >> > *Sent:* Sunday, November 22, 2020 4:19 PM >> > *To:* Jeffrey (Zhaohui) Zhang >> > *Cc:* Alvaro Retana ; BIER WG ; >> > EXT-zhang.zheng@zte.com.cn ; Tony Przygienda < >> > tonysietf@gmail.com>; draft-ietf-bier-ipv6-requirements < >> > draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com >> > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09 >> > >> > >> > >> > *[External Email. Be cautious of content]* >> > >> > >> > >> > Hi Jeffrey >> > >> > >> > >> > This has been a very informative exchange and extremely helpful for >> > all of us to get onto the same page from a basic understanding POV. >> > >> > >> > >> > Much appreciated all your help and feedback helping clarify my >> confusion. >> > >> > >> > >> > I am answering in-line but now connecting the dots how is in today=E2= =80=99s >> > RFC >> > 8296 Non MPLS BIER Ethernet going to transport IPv6? >> > >> > >> > >> > From your answers below it cannot work as we need two IANA code point >> > one for IPv6 next header type and ICMPv6. >> > >> > >> > >> > Zzh5> The existing model/concept works except that we need to two code >> > points if IPv6 tunneling is used for either getting over non-BFRs or >> > for FRR. One may deem non-BFR as a short-term scenario but FRR will be >> > here for the long run. >> > >> > >> > >> > Gyan4>I am a little confused here with the code points. For >> > BIERin6 =E2=80=9CL2=E2=80=9D BIER scenario RFC 8296 Non MPLS BIER Ethe= rnet Ether type >> 0xAB37. >> > >> > >> > >> > Ethernet -0xAB37 l BIER | IPv6 | payload >> > >> > >> > >> > Zzh6> Note that IPv6 header is not needed =E2=80=93 it should be Ether= net >> > Zzh6> -0xAB37 >> > l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6 >> > header may be inserted between BIER and payload, only for the SRv6 >> > style VPN purpose. >> > >> > Gyan> Understood >> > >> > Ethernet -0xAB37 l BIER l ICMPv6 | payload >> > >> > >> > >> > Zzh6> ICMP was mentioned not for encapsulation but for the following: >> > >> > Gyan6>Understood >> > >> > Zzh6> 2.1. IPv6 Options Considerations >> > >> > >> > >> > For directly connected BIER routers, IPv6 Hop-by-Hop or Destination >> > >> > options are irrelevant and SHOULD NOT be inserted by BFIR on the >> > >> > BIERin6 packet. In this case IPv6 header, Next Header field should >> > >> > be set to TBD. Any IPv6 packet arriving on BFRs and BFERs, with >> > >> > multiple extension header where the last extension header has a >> > Next >> > >> > Header field set to TBD, SHOULD be discard and the node should >> > >> > transmit an ICMP Parameter Problem message to the source of the >> > >> > packet (BFIR) with an ICMP code value of TBD10 ('invalid options >> > for >> > >> > BIERin6'). >> > >> > >> > >> > In this particular scenario where adjacent BFRs support Ethernet link >> > layer in an IPV6 environment and IPv6 or ICMPv6 encapsulation and the >> > need for the next header code point above is the packet format: >> > >> > >> > >> > Excerpt from RFC 8296 >> > >> > >> > >> > Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet >> > >> > header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332 >> > > > k.com/?url=3Dhttps*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Ce= tp >> > u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$ >> > defense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!! >> > NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8 >> > 4ssHlj%24&data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7C97b8a= 34 >> > 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7 >> > C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj >> > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D8EiHsMns5J= ut >> > 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&reserved=3D0>]. IEEE >> > >> > has assigned Ethertype 0xAB37 for non-MPLS BIER packets. >> > >> > >> > >> > >> > >> > In the case of BIERin6 optional encapsulation option, in case where >> > operators requires packets forwarded in IPv6 or tunneling over Non BFR >> > packet format below: >> > >> > >> > >> > IPv6 outer header l BIER l Data >> > >> > >> > >> > So here the next header is BIER so corresponding next header code poin= t. >> > >> > >> > >> > >> > >> > So below is for both cases IANA code point allocation for =E2=80=9CL2= =E2=80=9D next >> > header where next header is IPv6 or ICMPV6, and then the optional IPv6 >> > encapsulation option where the next header is BIER. >> > >> > >> > >> > Would those be two separate IANA code point requests I what I see from >> > the packet format. >> > >> > >> > >> > IANA L2 scenario: >> > >> > 2 code point requests for L2 for next header IPv6 and ICMP >> > >> > >> > >> > Zzh6> I don=E2=80=99t follow what you=E2=80=99re talking about. If BIE= R header follows >> > Zzh6> L2 >> > header directly, no new code point is needed. It=E2=80=99s just =E2=80= =9CEthernet >> > 0xAB37 | BIER | payload=E2=80=9D. >> > >> > >> > >> > Gyan6> Agreed. >> > >> > >> > >> > IANA optional IPv6 scenario: >> > >> > 1 code point request for IPv6 for next header BIER >> > >> > >> > >> > Zzh6> If IPv6 encapsulation is used, either on between directly >> > Zzh6> connected >> > BFRs or indirectly connected BFRs, a new =E2=80=9Cnext header=E2=80=9D= code point is >> > needed for BIER. >> > >> > Gyan6>Understood >> > >> > >> > 5 >> > < >> https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.c= om/?url=3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2= Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fp= nhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24&data=3D04*7C= 01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7C0= fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7CTW= FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3= D*7C1000&sdata=3DnEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&res= erved=3D0__;JSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueS= P2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N$ >> >. >> > IANA Considerations >> > >> > >> > >> > >> > >> > IANA is requested to assign a new "BIER" type for "Next Header" in >> > >> > the "Assigned Internet Protocol Numbers" registry. >> > >> > >> > >> > IANA is requested to assign a new "BIERin6" type for "invalid >> > >> > options" in the "ICMP code value" registry. >> > >> > >> > >> > IANA is requested to assign a new "BIER IPv6 transportation >> > Sub-sub- >> > >> > TLV" type in the "OSPFv3 BIER Ethernet Encapsulation sub-TLV" >> > >> > Registry. >> > >> > >> > >> > IANA is requested to set up a new "BIER IPv6 transportation >> > Sub-sub- >> > >> > sub-TLV" type in the "IS-IS BIER Ethernet Encapsulation sub-sub-TLV= " >> > >> > Registry. >> > >> > >> > >> > >> > >> > My point is that the IANA allocation is different as the next header >> > is different for the L2 scenario where next header is IPv6 or ICMPV6, >> > and IPv6 encapsulation scenario where the next header is BIER. >> > >> > >> > >> > Zzh6> If BIER header follows L2 header directly, BIER Ethertype is >> > Zzh6> used >> > (assuming Ethernet is the L2). >> > >> > Gyan>Understood >> > >> > Based on this point I am making could we just do a RFC8296 bis version >> > and add the IANA code points for IPv6 and ICMPv6. >> > >> > >> > >> > Zzh6> Given the confusion/contention that have happened in the last >> > Zzh6> two >> > years, it is much better to specifically have a spec dedicated to >> > supporting BIER in IPv6. >> > >> > Gyan6> I think now looking at it holistically speaking I can now see >> > parity between the L2/tunnel and L3/tunnel both also having the clean >> > layering. So I can see why adding existing L2/tunnel to BIERin6 even >> > though it already exists made sense to bundle into BIERin6 total >> > solution >> >> Juniper Business Use Only >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier >> > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000002a611705b58a73b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=C2=A0 =C2=A0 My comment =C2=A0on IPv6 not yet ubiquitous. =C2=A0

Granted IPv6 is not yet ubiq= uitous, however as the many benefits to be realized with SRv6, operators ar= e pushing fast to upgrade to RFC 5565 softwire mesh framework v4v6 edge ove= r a v6 only core. As operators shift there core to IPv6 over the next few y= ears BIER x-PMSI MVPN over SRv6 core will soon be ubiquitous and a reality.= =C2=A0 We are not to far off from a complete paradigm shift from v4 core to= ubiquitous v6 core.=C2=A0 This will happen much sooner then of course the = actual proliferation of IPv6 traffic worldwide which may take a lifetime.= =C2=A0 Although with 5G and network slicing that in itself will be a paradi= gm shift and also toward IPv6 only mobile and fixed 5G.


Regards= ,
Greg

On Mon, Nov 30, 2020 at 3:22 AM Adrian Farrel <adrian@olddog.co.uk> wrote:
Hey Jeffrey,

It may be because I'm late to the discussion, but when you say...

> With the above, there is simply no need for another solution in my vie= w.

...this seems to suggest that there is already a solution.
AFAICS, while you might support only one of the two solutions, there are tw= o solutions. Neither has been adopted and neither has been "selected&q= uot;.

You might have better phrased this as "this is simply no need for two = solutions." It might be true that most people agree with that, but sin= ce they will only agree if their preferred solution is chosen, it is possib= ly not very helpful.

However, you go on...

> Of course the WG can continue discussing BIERv6 and may determine that= it is
> nice to have BIERv6 as well, but we should not bundle them together wh= en it
> comes to adoption.

...which seems to suggest that you don't think it is harmful to discuss= two solutions.
Since the adoption of one on its own is likely to reduce the chances of ado= ption of the other, not bundling the adoptions might be a little simplistic= . I am not proposing that we poll the adoption of either solution first. No= r am I suggesting making it an either/or adoption poll.

So how about this?

- BIER has a history of starting with Experimental work and seeing how it d= evelops
- This deployment case is somewhat niche: multicast is a bit rare, BIER is = not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, br= idging over IPv6 is a subset of BIER.
- Why not adopt both approaches as Experimental and set some clear terms fo= r the experiment?

Cheers,
Adrian

-----Original Message-----
From: BIER <b= ier-bounces@ietf.org> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 28 November 2020 21:54
To: Michael McBride <michael.mcbride@futurewei.com>; gjshep@gmail.com
Cc: BIER WG <bier@iet= f.org>; Gyan Mishra <hayabusagsm@gmail.com>; draft-ietf-bier-ipv6-requirem= ents <draft-ietf-bier-ipv6-requirements@ietf.org>; EXT-zhang.zheng@zt= e.com.cn <zhang.zheng@zte.com.cn>; Alvaro Retana <aretana.ietf@gmail.com>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

To clarify, there is no gap in the BIERin6 solution (besides the new "= next header" code point). It's just that some text are needed to e= xplain how the requirements are met with the BIERin6 solution - whether it = is a requirement already listed in the current requirements draft, or have = been brought up in recent mailing list discussions (I know of two in recent= discussions).

BIERin6 is based on RFC 8296 (plus the new "next header" code poi= nt for IPv6 encapsulation), and is a generic solution with the following pr= operties:

1. clean layering - BIER over L2/tunnel and it can carry different payload = types including SRv6
2. IPv4/IPv6 independent (of course you need different signaling)
3. L2 independent - as long as the L2 header can indicate with a code point= that a BIER header follows
4. tunnel type independent - as long as the tunnel header can indicate with= a code point that a BIER header follows
5. can work one-hop or multi-hop tunnels nicely
6. can work with SRv6 based services nicely

With the above, there is simply no need for another solution in my view. Of= course the WG can continue discussing BIERv6 and may determine that it is = nice to have BIERv6 as well, but we should not bundle them together when it= comes to adoption. That's why I suggested in the last BIER session the= following:

- Adopt BIERin6
- Discuss BIERv6 further

Jeffrey

-----Original Message-----
From: Michael McBride <michael.mcbride@futurewei.com>
Sent: Saturday, November 28, 2020 2:15 PM
To: gjshep@gmail.com<= /a>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Alvaro Retana <aretana.ietf@gmail.com>; BIER = WG <bier@ietf.org= >; EXT-z= hang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <tonysietf@gmail.com&g= t;; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-require= ments@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]


Hi Greg,

>Thank you Jeffrey and Gyan for sticking with the thread of the conversa= tion to advance the discussion. It's clear now that all of the requirem= ents >discussed so far can be addressed by the BIERin6 draft if we flesh= out the discussed gaps.

>I would like to see Jeffrey and Gyan take over as primary authors of >BIERin6 to include the gaps discussed here so that it fully encompases = the requirements so far described, for WG adoption.

I'm sure I'm misinterpreting. What it sounds like you are saying is= "I want bierin6 to be adopted so let's fix the gaps so we can beg= in". Since both solutions meet the requirements, I'm hoping you me= ant "Let's fix the gaps in bierin6 so we can begin adoption calls = for both bierv6 and bierin6".

mike


On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Hi Gyan,
>
>
>
> Great that we reached consensus on BIERin6.
>
> Now there are two lingering points alluded to in this thread, but
> given it=E2=80=99s been such a long and deeply nested tread, I=E2=80= =99ll start a new
> thread about it.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Monday, November 23, 2020 1:32 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> That=E2=80=99s the last of my questions related to BIERin6.
>
>
>
> I thank you for taking the time to go over the BIERin6 draft in detail= .
>
>
>
> We have reached consensus as well as are in sync,=C2=A0 and I now have= a
> better understanding of BIERin6.
>
>
>
> During the discussions I did mention that maybe in BIERin6 optional > IPv6 tunneling should be removed, as it seemed to create some
> confusion, but now I am clear and as both the L2/tunnel and IPv6
> L3/tunnel encapsulation single hop or multi hop tunnel both have the > clean BIER layering and complement each other I agree they belong toge= ther in the same draft.
>
> Even though L2/tunnel exists today as part of RFC8296 it makes sense > to be part of the overall BIERin6 solution.
>
>
>
> I am clear on the two IANA code points requests required for the
> optional
> IPV6 encapsulation option.
>
>
>
> Over the course of this thread we did touch on some technical reasons<= br> > why
> IPV6 encapsulation is necessary which I you mentioned in some of your<= br> > responses.
>
>
>
> Overall throughout the discussions I agree that BIERin6 IPV6 tunnel > option and BIERv6 are not transitional and are long term solutions and=
> there are reasons why that we can add to the requirements draft as to<= br> > why IPV6 encapsulation is necessary below:
>
>
>
> - Operator requirement for IPV6 encapsulated packets=C2=A0 and not L2<= br> > encapsulation.
>
> -FRR
>
>
>
> I think we are all set to start updating the Requirements draft.
>
>
>
> In-line Gyan6>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper= .net> wrote:
>
> Gyan,
>
>
>
> Please see zzh6> below.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 9:49 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Agreed we have reached a consensus.
>
>
>
>
>
> Few more questions to iron out understanding.
>
>
>
> In line gyan4>
>
>
>
> Zzh6> Apparently there are still disconnects =F0=9F=98=8A
>
>=C2=A0 Gyan> Thank you for all the detailed responses.=C2=A0 We are = in sync now!
>
> On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper= .net> wrote:
>
> Hi Gyan,
>
>
>
> Yes I believe we=E2=80=99ve reached consensus.
>
>
>
> Please see zzh5> below about some details.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 4:19 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; BIER WG <bier@ietf.org>;
> EXT-zh= ang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>; Tony Przygienda <
> tonysietf@gma= il.com>; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> This has been a very informative exchange and extremely helpful for > all of us to get onto the same page from a basic understanding POV. >
>
>
> Much appreciated all your help and feedback helping clarify my confusi= on.
>
>
>
> I am answering in-line but now connecting the dots how is in today=E2= =80=99s
> RFC
> 8296 Non MPLS BIER Ethernet going to transport IPv6?
>
>
>
> From your answers below it cannot work as we need two IANA code point<= br> > one for IPv6 next header type and ICMPv6.
>
>
>
> Zzh5> The existing model/concept works except that we need to two c= ode
> points if IPv6 tunneling is used for either getting over non-BFRs or > for FRR. One may deem non-BFR as a short-term scenario but FRR will be=
> here for the long run.
>
>
>
>=C2=A0 =C2=A0 =C2=A0Gyan4>I am a little confused here with the code = points.=C2=A0 For
> BIERin6 =E2=80=9CL2=E2=80=9D BIER scenario RFC 8296 Non MPLS BIER Ethe= rnet Ether type 0xAB37.
>
>
>
> Ethernet -0xAB37 l BIER | IPv6 | payload
>
>
>
> Zzh6> Note that IPv6 header is not needed =E2=80=93 it should be Et= hernet
> Zzh6> -0xAB37
> l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6=
> header may be inserted between BIER and payload, only for the SRv6
> style VPN purpose.
>
> Gyan> Understood
>
> Ethernet -0xAB37 l BIER l ICMPv6 | payload
>
>
>
> Zzh6> ICMP was mentioned not for encapsulation but for the followin= g:
>
>=C2=A0 Gyan6>Understood
>
> Zzh6> 2.1.=C2=A0 IPv6 Options Considerations
>
>
>
>=C2=A0 =C2=A0 For directly connected BIER routers, IPv6 Hop-by-Hop or D= estination
>
>=C2=A0 =C2=A0 options are irrelevant and SHOULD NOT be inserted by BFIR= on the
>
>=C2=A0 =C2=A0 BIERin6 packet.=C2=A0 In this case IPv6 header, Next Head= er field should
>
>=C2=A0 =C2=A0 be set to TBD.=C2=A0 Any IPv6 packet arriving on BFRs and= BFERs, with
>
>=C2=A0 =C2=A0 multiple extension header where the last extension header= has a
> Next
>
>=C2=A0 =C2=A0 Header field set to TBD, SHOULD be discard and the node s= hould
>
>=C2=A0 =C2=A0 transmit an ICMP Parameter Problem message to the source = of the
>
>=C2=A0 =C2=A0 packet (BFIR) with an ICMP code value of TBD10 ('inva= lid options
> for
>
>=C2=A0 =C2=A0 BIERin6').
>
>
>
> In this particular scenario where adjacent BFRs support Ethernet link<= br> > layer in an IPV6 environment and=C2=A0 IPv6 or ICMPv6 encapsulation an= d the
> need for the next header code point above is the packet format:
>
>
>
> Excerpt from RFC 8296
>
>
>
>=C2=A0 =C2=A0 Therefore, if a non-MPLS BIER packet is encapsulated in a= n Ethernet
>
>=C2=A0 =C2=A0 header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC53= 32
> <https://urldefense.com= /v3/__https://nam11.safelinks.protection.outloo
> k.com/?url=3Dhtt= ps*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp
> u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$
> de= fense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!!<= br> > NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8=
> 4ssHlj%24&amp;data=3D04%7C01%7Cmichael.mcbride%40futurewei.com%7C= 97b8a34
> 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7=
> C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj=
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D8EiHsM= ns5Jut
> 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&amp;reserved=3D0>].=C2=A0 IE= EE
>
>=C2=A0 =C2=A0 has assigned Ethertype 0xAB37 for non-MPLS BIER packets.<= br> >
>
>
>
>
> In the case of BIERin6 optional encapsulation option, in case where > operators requires packets forwarded in IPv6 or tunneling over Non BFR=
> packet format below:
>
>
>
> IPv6 outer header l BIER l Data
>
>
>
> So here the next header is BIER so corresponding next header code poin= t.
>
>
>
>
>
> So below is for both cases IANA code point allocation for =E2=80=9CL2= =E2=80=9D next
> header where next header is IPv6 or ICMPV6, and then the optional IPv6=
> encapsulation option where the next header is BIER.
>
>
>
> Would those be two separate IANA code point requests I what I see from=
> the packet format.
>
>
>
> IANA L2 scenario:
>
> 2 code point requests for L2 for next header IPv6 and ICMP
>
>
>
> Zzh6> I don=E2=80=99t follow what you=E2=80=99re talking about. If = BIER header follows
> Zzh6> L2
> header directly, no new code point is needed. It=E2=80=99s just =E2=80= =9CEthernet
> 0xAB37 | BIER | payload=E2=80=9D.
>
>
>
>=C2=A0 =C2=A0 =C2=A0Gyan6> Agreed.
>
>
>
> IANA optional IPv6 scenario:
>
> 1 code point request for IPv6 for next header BIER
>
>
>
> Zzh6> If IPv6 encapsulation is used, either on between directly
> Zzh6> connected
> BFRs or indirectly connected BFRs, a new =E2=80=9Cnext header=E2=80=9D= code point is
> needed for BIER.
>
>=C2=A0 Gyan6>Understood
>
>
> 5
> <https://urldefense.com/v3/__http= s://nam11.safelinks.protection.outlook.com/?url=3Dhttps*3A*2F*2Furldefense.= com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07= *section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR= 14p1w2ObtXPqQ_dVL5sH*24&amp;data=3D04*7C01*7Cmichael.mcbride*40futurewe= i.com*7C97b8a3414dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc= *7C1*7C0*7C637420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL= CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=3DnEiVnn= CjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&amp;reserved=3D0__;JSUlJSUlJSU= lKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7= s_KsspK1DsMPGcaKe-PHwxls5N$ >.
> IANA Considerations
>
>
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIER" type f= or "Next Header" in
>
>=C2=A0 =C2=A0 the "Assigned Internet Protocol Numbers" regist= ry.
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIERin6" typ= e for "invalid
>
>=C2=A0 =C2=A0 options" in the "ICMP code value" registry= .
>
>
>
>=C2=A0 =C2=A0 IANA is requested to assign a new "BIER IPv6 transpo= rtation
> Sub-sub-
>
>=C2=A0 =C2=A0 TLV" type in the "OSPFv3 BIER Ethernet Encapsul= ation sub-TLV"
>
>=C2=A0 =C2=A0 Registry.
>
>
>
>=C2=A0 =C2=A0 IANA is requested to set up a new "BIER IPv6 transpo= rtation
> Sub-sub-
>
>=C2=A0 =C2=A0 sub-TLV" type in the "IS-IS BIER Ethernet Encap= sulation sub-sub-TLV"
>
>=C2=A0 =C2=A0 Registry.
>
>
>
>
>
> My point is that the IANA allocation is different as the next header > is different for the L2 scenario where next header is IPv6 or ICMPV6,<= br> > and IPv6 encapsulation scenario where the next header is BIER.
>
>
>
> Zzh6> If BIER header follows L2 header directly, BIER Ethertype is<= br> > Zzh6> used
> (assuming Ethernet is the L2).
>
>=C2=A0 Gyan>Understood
>
> Based on this point I am making could we just do a RFC8296 bis version=
> and add the IANA code points for IPv6 and ICMPv6.
>
>
>
> Zzh6> Given the confusion/contention that have happened in the last=
> Zzh6> two
> years, it is much better to specifically have a spec dedicated to
> supporting BIER in IPv6.
>
>=C2=A0 Gyan6> I think now looking at it holistically speaking I can = now see
> parity between the L2/tunnel and L3/tunnel both also having the clean<= br> > layering.=C2=A0 So I can see why adding existing L2/tunnel to BIERin6 = even
> though it already exists made sense to bundle into BIERin6 total
> solution

Juniper Business Use Only
_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier
_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier

On Wed, Dec 2, 2020 at 4:29 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
=
Hi Adrian,
you've said:
This deployment case is somewhat niche: multicast is a bit rare, BIER is n= ot widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, bri= dging over IPv6 is a subset of BIER.=C2=A0
I've pause= d on the second sentence. As I understand it, BIER is designed specifically= for multicast. Perhaps it is not yet as widely deployed comparing to the o= verall multicast deployments but I cannot name what else would benefit from= BIER as much as multicast. Is my interpretation close to the idea of that = sentence?
--
--0000000000002a611705b58a73b8-- From nobody Tue Dec 8 06:40:02 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973AD3A0D41; Tue, 8 Dec 2020 06:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, PLING_QUERY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qseK4Dfmo7t1; Tue, 8 Dec 2020 06:39:57 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BDD3A0F48; Tue, 8 Dec 2020 06:39:54 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D6C01548027; Tue, 8 Dec 2020 15:39:47 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CEDAD440041; Tue, 8 Dec 2020 15:39:47 +0100 (CET) Date: Tue, 8 Dec 2020 15:39:47 +0100 From: Toerless Eckert To: bier-chairs@ietf.org, aretana.ietf@gmail.com Cc: bier@ietf.org, gengxuesong@huawei.com, draft-ietf-bier-te-arch@ietf.org Message-ID: <20201208143947.GA22208@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Bier] BIER chairs/Alvaro: draft-ietf-bier-te-arch -> IESG ?! X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 14:40:00 -0000 [resending after one month of no-reply] Dear BIER chairs, Alvaro What is holding back subject draft to go to IETF review ? In discussion during IETF109 BIER-WG meeting, Alvaro confirmed that there is no further need to add additional unnecessary process steps, so AFAIK if you BIER WG chairs just click the right buttons in datatracker, the document should go to Alvaro for revew and then IETF/IESG review. Thank you very much Toerless (for the authors) In-Reply-To: <20201109221538.GA28949@faui48f.informatik.uni-erlangen.de> On Mon, Nov 09, 2020 at 11:15:38PM +0100, Toerless Eckert wrote: > Dear BIER chairs > > Xuesong's shepherd writeup for draft-ietf-bier-te-arch is on datatracker, > and she agrees it is ready to be passed to IESG, all open issues (IPR > ask to authors) where resolved). Datatracker still shows "IN WG Last Call". > > Would one of you do the honors of clicking the right button in datatracker > to kick the doc to Alvaro/IETF/ESG ? Or else, what's missing ? > > Thank you so much > Toerless From nobody Tue Dec 8 08:07:46 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DB63A0FFD; Tue, 8 Dec 2020 08:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PLING_QUERY=0.1, 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=gmail.com 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 7ua_dOVLi0-v; Tue, 8 Dec 2020 08:07:41 -0800 (PST) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E00B3A1059; Tue, 8 Dec 2020 08:07:30 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id b9so14994860ejy.0; Tue, 08 Dec 2020 08:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=6m8mT+0BZd2LHAPdG8iCVhMG/tx3FDOX6VTfpU0vad4=; b=vEJJJAG7xDM1J1nNQy1p7zW3Q+kGcpH/kqja+C7limsSCZBukasvddD47zvR/DPS3q YSxdDnsP3bwgxfbToanqkWS377EDPbSHFxuFJKvWs4/3+EhERe1Jj1r3RFADkg/Zhv4u oS03cIiGpR5YBgpqdyn3OyU3lIUfGzqDdDSVTvXLY+ng8jYe5V2JZ3igzYsMY8c+S0OP s7k3N++sSjLRl1Yv6oLI1IPYFa2CemeXsJZsyLzIMalfOSaMA1JSpdOweIy1SpmGgLL0 c7vb1rb3wSRkdN51hxRhaaw4+Kypc2oFMTXGDFUQBvhZPAU7XhUw//hA8O49gsxm9jzP bslg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=6m8mT+0BZd2LHAPdG8iCVhMG/tx3FDOX6VTfpU0vad4=; b=FXLxYRCWtWc7Z0cq2IZsEvY4vxlruezcP7A637rBc//kbeAper1NSNDj3U2waAoeuJ jLTlycCn10RDvFy5yVszNM8r2CHmL12Q4JdodeGLW4Lim1Ah2MgY0XMWaD6bSlKWCzH6 vTEv70kjBRFwJqHA7ySpEclm7Z8AdsuySrTzapqGrsSyyjD54TvOjpryPkbTD9VGBsPe Or7FZMuvSO2Vsh/3Fco3p151Nmk3wpD+TlJwcz04EaxUMMkXftV7nNVHwqeF0fAEKVR3 fgFvVYdmUXEcZ+J6hzWqmUqntDbA2eL+v4NpydkguPoiSTRzgIO71JLbsAzC3RaiYn3m HZ8w== X-Gm-Message-State: AOAM533hAEw5NLfJvW6rtzn7Wx7KHqWe9wk5EMT2ByZbLYFcoJltfrFe v+aw4NnVu4RdzCskKXvb88PPsqffmlGVnHoTeoM= X-Google-Smtp-Source: ABdhPJwMw2gW3zd1PP58xf6MQYaS7be9ZtnceH3/Nwyxuinp00WntcyrTRvgijU9OPcO6rtwBkZRY5GWbs0SsWWrcxg= X-Received: by 2002:a17:906:52c4:: with SMTP id w4mr23974444ejn.165.1607443648690; Tue, 08 Dec 2020 08:07:28 -0800 (PST) MIME-Version: 1.0 References: <20201208143947.GA22208@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20201208143947.GA22208@faui48f.informatik.uni-erlangen.de> Reply-To: gjshep@gmail.com From: Greg Shepherd Date: Tue, 8 Dec 2020 08:07:17 -0800 Message-ID: To: Toerless Eckert Cc: BIER WG Chairs , Alvaro Retana , BIER WG , "Gengxuesong (Geng Xuesong)" , draft-ietf-bier-te-arch@ietf.org Content-Type: multipart/alternative; boundary="000000000000ad476a05b5f6236d" Archived-At: Subject: Re: [Bier] BIER chairs/Alvaro: draft-ietf-bier-te-arch -> IESG ?! X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 16:07:45 -0000 --000000000000ad476a05b5f6236d Content-Type: text/plain; charset="UTF-8" Sorry, just hasn't boiled up to the top of the list. I'll move it along today. -Shep On Tue, Dec 8, 2020 at 6:40 AM Toerless Eckert wrote: > [resending after one month of no-reply] > > Dear BIER chairs, Alvaro > > What is holding back subject draft to go to IETF review ? > > In discussion during IETF109 BIER-WG meeting, Alvaro confirmed that there > is no further need to add additional unnecessary process steps, so AFAIK > if you BIER WG chairs just click the right buttons in datatracker, the > document should go to Alvaro for revew and then IETF/IESG review. > > Thank you very much > Toerless (for the authors) > > In-Reply-To: <20201109221538.GA28949@faui48f.informatik.uni-erlangen.de> > > On Mon, Nov 09, 2020 at 11:15:38PM +0100, Toerless Eckert wrote: > > Dear BIER chairs > > > > Xuesong's shepherd writeup for draft-ietf-bier-te-arch is on datatracker, > > and she agrees it is ready to be passed to IESG, all open issues (IPR > > ask to authors) where resolved). Datatracker still shows "IN WG Last > Call". > > > > Would one of you do the honors of clicking the right button in > datatracker > > to kick the doc to Alvaro/IETF/ESG ? Or else, what's missing ? > > > > Thank you so much > > Toerless > --000000000000ad476a05b5f6236d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, just hasn't boiled up to the top of the li= st. I'll move it along today.

-Shep

<= div class=3D"gmail_quote">
On Tue, Dec= 8, 2020 at 6:40 AM Toerless Eckert <tt= e@cs.fau.de> wrote:
[resending after one m= onth of no-reply]

Dear BIER chairs, Alvaro

What is holding back subject draft to go to IETF review ?

In discussion during IETF109 BIER-WG meeting, Alvaro confirmed that there is no further need to add additional unnecessary process steps, so AFAIK if you BIER WG chairs just click the right buttons in datatracker, the
document should go to Alvaro for revew and then IETF/IESG review.

Thank you very much
=C2=A0 =C2=A0 Toerless (for the authors)

In-Reply-To: <20201109221538.GA28949@faui48f.informa= tik.uni-erlangen.de>

On Mon, Nov 09, 2020 at 11:15:38PM +0100, Toerless Eckert wrote:
> Dear BIER chairs
>
> Xuesong's shepherd writeup for draft-ietf-bier-te-arch is on datat= racker,
> and she agrees it is ready to be passed to IESG, all open issues (IPR<= br> > ask to authors) where resolved). Datatracker still shows "IN WG L= ast Call".
>
> Would one of you do the honors of clicking the right button in datatra= cker
> to kick the doc to Alvaro/IETF/ESG ? Or else, what's missing ?
>
> Thank you so much
>=C2=A0 =C2=A0 =C2=A0Toerless
--000000000000ad476a05b5f6236d-- From nobody Thu Dec 10 09:36:23 2020 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B44AD3A0EE0; Thu, 10 Dec 2020 09:36:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Greg Shepherd via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Cc: gengxuesong@huawei.com, bier@ietf.org, bier-chairs@ietf.org, iesg-secretary@ietf.org, Xuesong Geng Message-ID: <160762178172.9049.14370038215396179112@ietfa.amsl.com> Date: Thu, 10 Dec 2020 09:36:21 -0800 Archived-At: Subject: [Bier] Publication has been requested for draft-ietf-bier-te-arch-09 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 17:36:22 -0000 Greg Shepherd has requested publication of draft-ietf-bier-te-arch-09 as Proposed Standard on behalf of the BIER working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ From nobody Sun Dec 13 08:58:16 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B5C3A03EC for ; Sun, 13 Dec 2020 08:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=venaas-com.20150623.gappssmtp.com 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 fzfmx39__ubk for ; Sun, 13 Dec 2020 08:58:13 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01493A03C9 for ; Sun, 13 Dec 2020 08:58:13 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id g20so6512338plo.2 for ; Sun, 13 Dec 2020 08:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=B9qh3gZgFZpKRk3kt6O1/HSqYGA6oqPMxgyssa0hTtA=; b=ua9J4hnQR/yLEhq4Cjsa21pTzEDMBeokNS3NelQqiv+U/Obj+YROA8UnTgDzX3RnMs VGK76OhVTbsoKn6oLSUaWvt+NKdp+M2rwP1HMQnJtBSRGhta1WM3aTccKwAEALT05SYI YYUP0+Bvxz03O3pamiie/Pf/J3VLu5JxOlza6REA0FJWUGZ0JN3KBKd5YkZxGPWB+BLz 0mdpeRJmKy+pDNJ8jQqc6vOLVX/4NcAIJfVla084gakC6mvq99ni7b1gvAedJxAXPpdy OoAmh79Pkqae4pS6FXVoIjUqjwWuCT2QWU/NUB/ja/zUCMX90ThuSLaziPpMJikbmu7Y 8xCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=B9qh3gZgFZpKRk3kt6O1/HSqYGA6oqPMxgyssa0hTtA=; b=Suo3NdfJcMGmcMlsb1v85bEhFHaNMqCzNoNCBS9s+Aa4mrx4uhGNZszaxp33/kBM0o 195qD5tKT+mCYa0Qra5To9u3gPjnOgiul7YEoj3mORDuUFxDAjnfz57BzK7EXEgbSjoK iEnvQAj6Y9yDOtxWlXLLt2lvqRpPLIzHwd4Pc5DtTjihg5NjzETJ35Tj/DKn+e4phasW vUjSE4Z0dHsWTHDwdoaI+kjIKpCAqEUocPN9S/gXs1L0vdrez+nzGvp5dWtWTG+d0H/9 o4dgMJjp9luU3UjaROlWvcvb6QoJOWUAIc7pcMzNsVl6GiqfM9aJ70FsnUp1389thbNT Eykg== X-Gm-Message-State: AOAM5322Gs1AceeGFAzs10HXZdX6SnbhuEPdd6Q/9lSyJcEJ0RZSO2Li XhsGs2eLf6S/WybejTcGaW6+8+k2olzO4rHz6GIIuIVRjrAPOw== X-Google-Smtp-Source: ABdhPJxsK+s9WIM4oQGPNhf714y+LqjOFEsFsTmSaO3BaWnMj5L8JhkMZYxhEuH0+wRB4pdjujFnFqehBO1XAS4DuOQ= X-Received: by 2002:a17:90a:430f:: with SMTP id q15mr625493pjg.218.1607878692999; Sun, 13 Dec 2020 08:58:12 -0800 (PST) MIME-Version: 1.0 From: Stig Venaas Date: Sun, 13 Dec 2020 08:58:02 -0800 Message-ID: To: BIER WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Bier] WGLC in pim for draft-ietf-pim-igmp-mld-extension-02 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2020 16:58:15 -0000 Hi The IGMP/MLD BIER overlay makes use of this draft in pim, and it is now in WGLC in pim. In order for the MLD overlay to be published, we need the pim draft to be published as well. If you're interested, please read https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-extension-02 and respond to the WGLC in pim. I'm asking as an author of the draft (not as pim chair) Thanks, Stig