Re: [Bier] AD Review of draft-ietf-bier-pim-signaling-11

"Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com> Thu, 22 July 2021 23:38 UTC

Return-Path: <hooman.bidgoli@nokia.com>
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 715E03A1262; Thu, 22 Jul 2021 16:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.352
X-Spam-Level:
X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 Kb8PmTnX8xCl; Thu, 22 Jul 2021 16:38:52 -0700 (PDT)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2097.outbound.protection.outlook.com [40.107.93.97]) (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 ECC213A1261; Thu, 22 Jul 2021 16:38:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UWi7RVjwjHtLCyrIBZSTdpumR6enEek6z7P4r7CgdP9AqqjdnH/crl0AUh7m8djCo1cnzr5GV0kMUeynzs2/ZMn+0wORTwWM7Wuv2iaGFFD0f9usbyKxCa1Sj7dCD886wYAvFTGwAt/pjRsLULn7hGCZkbMLikWnuMYkvo3KoGpWYAeV6bO+B6+aeMzWhzS7rl7dfFFTsllTDL8zJ9qxv3lAew4DfCNy6fyeT0AEUF46dwEvYhb66SNcf82e1ZLbcgX7I4NEx3cg7EUrGI1NZoWxijn9XnT6pFlHtBnt49ARHcPrJuqT3aZy8+ahYWLn+NLT8tSz5ucsrC+uowktZA==
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=IeunAyh6Z4rhqztnaqpczvnO8+kh0ciRTmQoVtPlu+o=; b=i1zIqfzmS8TMt/P7oEkWGlZov97OUpq/kjWJXO8QzoUPIEBYDeaaUPF2T02vURXuiJmwMGjlAM+k3suBQd8KTcMeNpExMs6QDAgBBWCyZDlwVAaMbaNqItMw3y086RhUi9F4fX/DFfwhZs+rvh5YPT+s3VLp2FcLvMIGuKjGGykPDJ3JWDjTGDO4EFXK+Q8cVoRepIiO0E7CBNy++t++HZ5DDBvxEQHhIeZJqhy2f4r93LGSCLSoaH21apIqdJaMNGjLUlIKvITcs/wKpNUMCU8n3KFgRoII32U0lLZoUVxxewgjE11ZQ79dQB7vWkea1Laz3mOvqm7deMnZ4ZJilw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IeunAyh6Z4rhqztnaqpczvnO8+kh0ciRTmQoVtPlu+o=; b=J7RnQeVKX7B5+JeT065mmcqbBWek3vxw0u2rV3TC/xAwqOPFac2yz5XPqXaQpwxdLU08cSlPqq4ixuGNvtBv9JagRdiBO5sPmmg+CcN2ZBszC7m4tA/HDlDpcIuAYDkYGtxgp1fjPaiA2MemZMAii5PBhzW3QwlOO3fpH7IcM7U=
Received: from DM6PR08MB3978.namprd08.prod.outlook.com (2603:10b6:5:82::29) by DM6PR08MB4299.namprd08.prod.outlook.com (2603:10b6:5:97::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.29; Thu, 22 Jul 2021 23:38:46 +0000
Received: from DM6PR08MB3978.namprd08.prod.outlook.com ([fe80::1c65:f363:936e:71de]) by DM6PR08MB3978.namprd08.prod.outlook.com ([fe80::1c65:f363:936e:71de%6]) with mapi id 15.20.4331.032; Thu, 22 Jul 2021 23:38:46 +0000
From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-bier-pim-signaling@ietf.org" <draft-ietf-bier-pim-signaling@ietf.org>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
CC: "pim@ietf.org" <pim@ietf.org>, Nabeel Cocker <nabeel.cocker@gmail.com>, BIER WG <bier@ietf.org>, BIER WG Chairs <bier-chairs@ietf.org>
Thread-Topic: AD Review of draft-ietf-bier-pim-signaling-11
Thread-Index: AQHXZtOAB//W1/5+Wka2TzHgzq2QRqtMeyEAgAGXAzA=
Date: Thu, 22 Jul 2021 23:38:46 +0000
Message-ID: <DM6PR08MB397833FCFA996F806862C7AE91E49@DM6PR08MB3978.namprd08.prod.outlook.com>
References: <CAMMESsxi--FSuZrsbxFs3vCXdyv9vp8C9e0iyjNVERNffUrB1g@mail.gmail.com> <CAMMESsyXbqU4NN8MOY4bo0Mh40FMM96tTCbYrYHsBrjahJh59Q@mail.gmail.com>
In-Reply-To: <CAMMESsyXbqU4NN8MOY4bo0Mh40FMM96tTCbYrYHsBrjahJh59Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-Mentions: zzhang@juniper.net
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8ca7cc3b-3140-41f5-bf5f-08d94d69d995
x-ms-traffictypediagnostic: DM6PR08MB4299:
x-microsoft-antispam-prvs: <DM6PR08MB4299804FF0901998E2A9A5E691E49@DM6PR08MB4299.namprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zkjniGfetXrkd1psZkGoKXBbSCRIxEfc9dJhlQbJoVl055/lnW8SoBfyTFbECXkdtC6bEhforO+sFEGTMbPuHv/VPlI/P3KzyTW4EP5WTlRbhLEr0vvshrZnV9n9GT1KtTAYxJ7EJTy3A96iLDHR+z6YkkQtNaeDF2r1pczUh/ozZEcyLu0ZKNc7Q7ks50LmwrxPlNp9oPHqxW0BM5HcHyaLs0R8cjaRzS/NJsNq29GIbYYG8fDaz8yThN1I1APmGkQQgr4YmBFMaVEJwOmziI+qHgQx7YU5LhtChdhkbaanIoK1UIhyTPRGY96QY1QLBrQGOPCIyfpvwq9F4e7qJqyRJ/TuWScJC6KM3Alb/q0r+x4QmCLxh6/wHuUh1Ae3A68mCRx2ljr9ptE3nqDkRmugnqNfgSK8omj/WWx6ul9Vol4Epwt6Svg72rjM7AtgmYqA1ZCxkpi5P9OHpOlsU0Tf/cBSCM6RXRs0XUvMDzVYwCjWjX/+41yxpdMAn7/E5oU3+2nFbd+LBfUbK1zC3nv53B4OXkYs3D7EIlJbvLnppi6PtOfDYLeDAezdAFk5Jm7psf2khDhnipwH/PMSEqlq0qJSm9ERPYiG+3bYnF7QIeEE9Nxn0Tko8A9Dm6j2IZVGoikOpop3wJsMNnT0KA8FPz2DyltvoOOpu4LpWzeTx3ThvFbbx1+RygDt0aR4lVRI3eGmhuM/ymg/DBplZcxjre7UEoAeccP0P6Lh/B/GqL1N0LOjO6TXs9i2ZejESy63xG+Ujy0SAHLGYRHbOZlAxTmCeODcnhqzuncdg6213DQxdQyNP5TN1g41PTa+820b1PgJmxIzYQjzuNYfHg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB3978.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(376002)(346002)(39860400002)(396003)(4326008)(66574015)(7696005)(64756008)(5660300002)(186003)(99936003)(110136005)(83380400001)(71200400001)(30864003)(26005)(76116006)(66476007)(66446008)(66556008)(66946007)(55016002)(52536014)(33656002)(478600001)(54906003)(66616009)(8676002)(2906002)(9686003)(38100700002)(122000001)(966005)(86362001)(166002)(316002)(8936002)(6506007)(53546011)(38070700004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?K3R1RFRsejdsb0VVQmhWODBrSGdmZVV0SEdlN2s1ckM1Nm5jSEd5NklqV1VE?= =?utf-8?B?RVQxUE96a2FCcEVSVk44RzlWUDlvT0FSSlRPaStLRi93LzBNSjZjTWY0VmVO?= =?utf-8?B?WVlINlBIb2FndUJWRm50WUgwS1BHdTVCS2FmdjI2VzM2N2lzd2pxaWxEcEEy?= =?utf-8?B?Uk51aGFsYlNGc2VYUDVPS2cwdFNIUzFjbDBnSkZ3U1ZjSGc0RFFvYS9YSTBw?= =?utf-8?B?S2V5N1BIZkpNcXpxanZDWXY4WHJ1Vnl6dzNyYkhaSk5KRW5DL0lsMUZJSnAw?= =?utf-8?B?akwrbXcwZ1pveHpPbjZyTVNhTXBaR1dSVnVxcjBDVDNYbnFmMml0YzJKR2dH?= =?utf-8?B?WmRpVS9vK1dKVTRJWkt2QnhreVdXWk8wNE9Rd29aV2FGUHF1Um5wZENKd2s0?= =?utf-8?B?Y2lBam5CVXpERGdaSUR4YjVBMlNESGEyUDRqSXJYelhwQ3NRTTQ4S3llN2Vq?= =?utf-8?B?cVdiTDNOMzVYeGVSWGNtWUVKUHovT2RzU2RNUzNXazFIM3BGNkxvY2VncFVV?= =?utf-8?B?Rm1WaGxwa1NaRjczZkdRcEk1ZXhIYkNRWUdMZDBXZmpjR1RKVys5Z3ZidSsr?= =?utf-8?B?SEIwMVZXR0hUaERyME0wdC9LR21tSUlhSThTUkhLaWJKWW0veVJPMi9LY1hu?= =?utf-8?B?UjBlOVNmb2JxWHQ0MUVPYU1MVXNSWEd1SWNzb2J0LzhFUGVzL3FBVFZBZnN0?= =?utf-8?B?czRmZ0trYkRuMVlqMWlHL0FkR2h5TlRPSWVLTlgrd3YvaE45anVZbDNqbkpM?= =?utf-8?B?UWF5b2M0YWY4bklWVytjdTUwNXVVb3VuZi81NmM3TVFmQk4yOUNnMXlGMDRu?= =?utf-8?B?RUdzaGd2KzRXUFVnRmhnbGp6UGREbC9vSWFYYnJkQmlsdkF5eUNNaGNzQSt6?= =?utf-8?B?VWt6aXZDc1BZMll3ZGRBallnNEFaSXBMb3ZyMjV3T3ltaVhLTFpmdSs2b1Zr?= =?utf-8?B?eHZxVk83S2lmTnp3eThDdlNvc1JUN0duZTFLVHNiSlNVZ2FlenJjbE9XQkxl?= =?utf-8?B?dXB4QTZyLzJhd1gzcEUzc05PRndFbDBQVitaQ2c0TzJiV0ZTMlBzR0U4a2tk?= =?utf-8?B?YXNpNnkrY0VxNUNnNC9sTFc3WFEvUGhwV3BPSVJCcytiVEpqYStyaXBkOU1r?= =?utf-8?B?VG9IYm5oS0lXcTdqNXJ2Yk1aWDh6MTNUTWdkNnYwR0NWdmdyZTJVS1VvN3ly?= =?utf-8?B?Yk1nUmNmeGxrc3YrMmw4cUZDZHhLZE1EK3ZWcm9Ed3FZKytCVlBpL3ZMREFx?= =?utf-8?B?Qi9ORng2RDlHQ2lIUzExYkRjeFNyWkk3LzZSUzB1dzdxTWNqOEhJeDkySi9h?= =?utf-8?B?czliNHVKSFZ4RXN2SXRxcDNOVGFPUVRFdm1hdzBhclhuYW9jcU9FR3J4VWg1?= =?utf-8?B?aUhsSW5ObzVIVnY2VGlYMmdpMXJQNG4rOC9BUm9LS2p6MGZPSGdLbkUzVWRi?= =?utf-8?B?MVhHMm9qMG9waDZNRXh3NWdHU2puRkRwOWN0NTJYNkpLeTdtY0I3QVNXanBK?= =?utf-8?B?dnVBOXVBVTIwS1NxME5HNW54MXZJaEQ1TkZGcTBSMVIxWCt3UUZVaXdzOFoy?= =?utf-8?B?RExZWFlXQlE0Yyt1bHZxeTR5UjY3a2g2UTdIaVNJRk9YbG5FcFdkdFRtVGxi?= =?utf-8?B?a2dreEQ4eGlid1R1aE9UMjJTRUs4bVpJWHRYVjlBLzFRUGxCWUtaRGRiQldX?= =?utf-8?B?VmJ4NzB3TWtWRENxUDgvZU1wdGdha3dwbmFMZmhNQ2lNbTYzdlliN1lxQ3RZ?= =?utf-8?Q?4NjPOFe4JMU5llqJf2bsB7W9/9PPrS1g6iiyzvI?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_004_DM6PR08MB397833FCFA996F806862C7AE91E49DM6PR08MB3978namp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB3978.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8ca7cc3b-3140-41f5-bf5f-08d94d69d995
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2021 23:38:46.5721 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QhDpw0JpVXbbQnAanEnl/+Ejrb4sPwZ0vJu0k1KSbq0O9jn8za4Gs/3SQ51ycO+TmAMi0EiC9fQ4NB9742SfCHfVn7JjdVEZBJQew+Ah3dA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4299
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/PKVYEu6brN61ttTMqzIYFYBOIxE>
Subject: Re: [Bier] AD Review of draft-ietf-bier-pim-signaling-11
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jul 2021 23:39:00 -0000

Hi Alvaro

Thank you again for going through the draft. Attach is the modified draft with your suggestions. I wasn’t sure if I should upload it or forward it.

Also some points below.

Thanks
Hooman



[major] What should a receiver do if the BFR-id doesn't match the BFIR-id in the BIER Header?
HB> not much can be done here, the reason we added the PIM information vector was because some HW couldn’t read into the BIER header. Ideally this attribute is not needed but we agreed on it because of explained reason.


[major] Are there any considerations related to the interaction with other PIM Join attributes?  For example the Vector attribute.  I am asking both from the point of view of the IBBR receiving other attributes from the PIM domain, *and* the IBBR including/forwarding them through the BIER domain.  If any of the received attributes are transitive, should they be forwarded through the BIER domain?
HB> this is explained in the start of the draft, only join/prune messages are signalled through bier domain we are not trying to create a PIM adjacency, it just so happened these signaling packets are pim join/prunes with PIM join attribute


[major] Compliance with rfc7761.



Even though it is not explicitly mentioned until §5, I want to talk about not sending Hellos and the overall compliance with rfc7761 here.



TL;DR: as written, not sending Hello messages is not compliant with rfc7761.
HB> not following we are not trying to do PIM adjacency over BIER in this draft. WE clearly mentioned at the beginning of the draft
HB> This tunneling is only done for signaling purposes and not for creating a PIM adjacency between the two disjoint PIM domains through the BIER domain. And in the new introduction
HB> for the rest of the points, again we are just using these exist messages as a new signaling purpose and it has nothing to do with RFC 7761. This is why we keep saying that the IBBR/EBBR will terminate the PIM adjacency.


[major] As mentioned before, not including Hellos may cause some issues (including not conforming to rfc7761).  It is not clear to me that the justification ("such functionality related to these other type of massages will not be possible") applies to Hellos.  What about the capabilities, what is expected?  How does the IBBR know if the EBBR even supports Join attributes??
HB> again toward the BIER domain it has nothing to do with RFC 7761. Toward bier domain it is just BIER signaling of PIM join/prune messages. Think of it as stitching of BIER to PIM where BIER uses PIM join/prune messages as its signaling of <S,G> or <*,G>. This is very clear in the draft.


444     6.  Applicability to MVPN



[] This section starts by saying that "With just minor changes, the above procedures apply to MVPN", but the description goes into more that "minor changes" (including a potential "more complicated label allocation scheme") and points at other details not properly specified.  If you want to include the MVPN case, then this section will need more details, references, etc.



Personally I would suggest removing it.
HB> Coauthors made this call @Jeffrey (Zhaohui) Zhang<mailto:zzhang@juniper.net> he can comment.


Suggestions>

   Figure 5 shows BGP enabled between the EBBR (B) and the IBBR (D), and

   it is used to distribute the routes from the the PIM Domain through the

   BIER domain, including the Multicast Source IP address (S).  The peering

   address used for BGP should belong to the same block as the BFR-prefix if

   the EBBR  to ensure that all routes from the PIM domain are resolved via

   the EBBR's BFR-prefix as their next-hop.

HB> this is nothing to do with BGP peering. BGP is doing nexthop self and the it should use the same loopback address for the nexthop as the BIER prefix ID. So IBBR can resolve the EBBR based on the source IP.
HB> suggestion
Suppose BGP is enable between EBBR (B) and IBBR (D) and the PIM Domain routes are redistributed to the BIER domain via BGP, performing next-hop-self for these routes. This would include the Multicast Source IP address (S). In such case BGP should use the same next-hop as the EBBR BIER prefix. This will ensure that all PIM domain routes, including the Multicast Source IP address (S) are resolve via EBBR's BIER prefix address. When the host (h) triggers a PIM join message to IBBR (D), IBBR tries to resolve (S). It resolves (S) via BGP installed route and realizes its next-hop is EBBR (B).

Regards
Hooman


From: Alvaro Retana <aretana.ietf@gmail.com>
Sent: Tuesday, July 20, 2021 4:18 PM
To: draft-ietf-bier-pim-signaling@ietf.org
Cc: pim@ietf.org; Nabeel Cocker <nabeel.cocker@gmail.com>om>; BIER WG <bier@ietf.org>rg>; BIER WG Chairs <bier-chairs@ietf.org>
Subject: Re: AD Review of draft-ietf-bier-pim-signaling-11

Ping!


On June 21, 2021 at 3:27:22 PM, Alvaro Retana (aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>) wrote:

Dear authors:

Thank you for your work and the patience through the publication process.


I just finished reading this document -- it still needs work!   In general, tightening up the specification is needed -- this is a Standards Track document!   Also, as written, this document is not compliant with rfc7761 -- I included most of my concerns about this point in §3.1.3.1 (search for line 338).


There are some process issues (listed in increasing severity) that I need the Chairs'/Shepherd's input on:

(1) 6 authors are listed in the front page, but rfc7322 recommends a limit of
    5.  Chairs: Can you please provide justification for going over the
    limit?  [In general, I think that 6 is an ok number -- we just need to cross the T's...]


(2) I didn't see a specific request from the Chairs asking the pim WG to
    review, or them being cc'd in any of the WGLCs.  Did I miss it?  Given
    the amount of PIM content in this document, that interaction should have
    already happened.

    I realize that there's a significant overlap in participation between the
    two WGs, so I'm cc'ing pim on this message and will forward the IETF LC
    when we get to that stage.


(3) This document replaces draft-hfa-bier-pim-signaling, but that linkage had
    not been indicated in the datatracker when Publication was requested.
    The main issue with this oversight is that draft-hfa-bier-pim-signaling
    has two IPR declarations [1].  The Shepherd's writeup says that no IPR had
    been filed against this document.  Also, I didn't find an IPR poll in the
    archives.

    I have added the link between this document and
    draft-hfa-bier-pim-signaling.

    To address this issue, I need the Chairs to please poll the authors about
    any non-declared IPR.  Please cc the WG (in case anyone else needs to
    declare something) and include a link to the existing disclosures.  Once
    each author has individually replied, I need the Shepherd to update the
    writeup.

    [1]
    https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bier-pim-signaling



Finally, I have a general question about the need/applicability for this work.  This is just for my own education:

What is the advantage/difference between using the specification in this document and unicast-tunneling the PIM messages to the corresponding node (EBBR)?  I see the discovery of the EBBR as one of the differences, but that discovery is outside the scope of this document -- IOW, the same procedures could be used to discover the target node without the additional BIER machinery.

Again, I'm just curious.  I suspect other reviewers may have similar questions.


Thanks!

Alvaro.



[Line numbers from idnits.]


...
18 Abstract

[nit] The First two paragraphs could be merged to provide continuity.


20   Consider large networks deploying traditional PIM multicast service.
21   Typically, each portion of these large networks have their own
22   mandates and requirements.

24   It might be desirable to deploy BIER technology in some part of these
25   networks to replace traditional PIM services.  In such cases
26   downstream PIM states need to be signaled over BIER Domain toward the
27   source.

[nit] s/over BIER Domain/over the BIER Domain


29   This draft explains the procedure to signal PIM joins and prunes
30   through a BIER Domain, as such enable provisioning of traditional PIM
31   services through a BIER Domain.

[minor] s/explains/specifies


[minor] s/ joins and prunes / Join/Prune messages /g

Please make sure, throughout the document, that the rfc7761 terminology is followed.


[nit] s/as such enable/enabling the


...
98 1.  Introduction

100   Consider large networks deploying traditional PIM multicast service.
101   Typically, each portion of these large networks have their own
102   mandates and requirements.

[minor] The Introduction is an exact copy of the Abstract.  That in itself is not necessarily a bad thing.  However, you might want to take the time here to maybe explain about what the different "mandates and requirements" are that would result in needing to signal PIM through the BIER domain.  [This is related to my question at the top about the need/applicability.]


...
113 2.  Conventions used in this document

115   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
116   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
117   document are to be interpreted as describe in [RFC2119].

[major] Please use the template from rfc8174.


119 2.1.  Definitions

121   Some of the terminology specified in [RFC8279] is replicated here and
122   extended by necessary definitions:

[major] Please don't replicate the terminology -- this way we can avoid the terms falling out of sync or being defined/understood differently.  Instead, make it clear what the expectations are:

Suggestion>
   An understanding of the BIER architecture [RFC8279] and the related
   terminology is expected.

New terms are ok in this section.  Extensions not so much because they may change the definition of a term in rfc8279, but a clarification is ok.


...
153   BBR:

155   BIER Boundary router.  A router between the PIM domain and BIER
156   domain.  Maintains PIM adjacency for all routers attached to it on
157   the PIM domain and terminates the PIM adjacency toward the BIER
158   domain.

160   IBBR:

162   Ingress BIER Boundary Router.  An ingress router from signaling point
163   of view.  It maintains PIM adjacency toward the PIM domain and
164   determines if PIM joins and prunes arriving from PIM domain need to
165   be signaled across the BIER domain.  If so it terminates the PIM
166   adjacency toward the BIER domain and signals the PIM joins/prunes
167   through the BIER core.

169   EBBR:

171   Egress BIER Boundary Router.  An egress router in BIER domain from
172   signaling point of view.  It terminates the BIER packet and forwards
173   the signaled joins and prunes into PIM Domain.

[major] I would have expected for the IBBR/EBBR to be defined as specific types of a BBR, but the definition doesn't do so.  For example, the BBR "Maintains PIM adjacency for all routers", as does the IBBR, but the EBBR doesn't.  IOW, it looks like the EBBR is not a BBR.   Please review and update the definitions.


...
193 3.  PIM Signaling Through BIER domain
...
208   As per figure 1, the procedures of PIM signaling is done at the BIER
209   boundary router.  The BIER boundary routers (BBR) are connected to
210   PIM capable routers toward the PIM domain and BIER routers toward the
211   BIER domain.  PIM routers in PIM domain continue to send PIM state
212   messages to the BBR.  The BBR will create PIM adjacency between all
213   the PIM routers attached to it on the PIM domain.  That said the BBR
214   does not propagate all PIM packets natively into the BIER domain.
215   Instead when it determines that the PIM join or prune messages needs
216   to be signaled through the BIER domain it will tunnel the PIM packet
217   through the BIER network.  This tunneling is only done for signaling
218   purposes and not for creating a PIM adjacency between the two
219   disjoint PIM domains through the BIER domain.

[] Suggestion>
   Figure 1 illustrates the operation of the BIER Boundary router (BBR).
   BBRs are connected to PIM routers in the PIM domain and BIER routers in
   the BIER domain.  Each BBR determines if a PIM Join or Prune message
   needs to be signaled through the BIER domain and tunnels it through the
   BIER network if so.  This tunneling is only done for signaling purposes
   and not for creating a PIM adjacency between the two disjoint PIM domains
   through the BIER domain.


221   The terminology ingress BBR (IBBR) and egress BBR (EBBR) are relative
222   from signaling point of view.

[minor] s/are relative from signaling/is relative only from a signaling


224   The ingress BBR will determine if an arriving PIM join or prune needs
225   to be signaled across the BIER domain.  While the egress BBR will
226   determine if the arriving BIER packet is a signaling packet and if so
227   it will generate a PIM join/prune packet toward its attached PIM
228   domain.

[minor] The first sentence is redundant with the text above.


230   The BFER and BFIR are BBR from datapath point of view.  It should be
231   noted the new procedures in this draft are only applicable to
232   signaling and there are no changes from datapath point of view.

[minor] I think that mixing the term BBR (defined in this document for signaling purposes) with BFIR/BFER (at this point) may cause unnecessary confusion.

Suggestion>
   The new procedures in this document are only applicable to PIM signaling.
   There are no changes to the datapath.


234 3.1.  Ingress BBR procedure

236   IBBR will create PIM adjacency to all PIM routers attached to it
237   toward the PIM domain.

[] Suggestion>
   The IBBR maintains a PIM adjacency [RFC7761] with any PIM router attached
   to it on the PIM domain.


239   When a PIM join or prune for certain (S,G) arrives, the IBBR first
240   determines whether the join or prune is meant for a source that is
241   reachable through the BIER domain.  As an example, this source is
242   located in a disjoint PIM domain that is reachable through the BIER
243   domain.  If so the IBBR will try to resolve the source via an EBBR
244   closest to the source.

246   The procedure to find the EBBR (BFIR from datapath point of view) can
247   be via many mechanisms explained in more detail in upcoming section.

[major] "certain (S,G)"  It is not until §5 that you mention the use of the mechanisms with ASM.  The text throughout the document feels as if the operation applies *only* to SSM becasue of the specific used of "source".  Please mention the applicability earlier so the reader doesn't have to make assumptions.  Including something in the Introduction would be ideal -- maybe move a part of §5 there.

Also, some of the text will have to be updated to reflect the use of the source or RP.


[major] Related.  The mechanisms in this document work to join/leave the RPT, but not for a source to send Register messages to an RP across the BIER domain.   Given that the Register messages are unicast, they should make it to the RP without additional changes, right?  It would be good if this was explained somewhere.


[major] "mechanisms explained in more detail in upcoming section"   There are examples later on, but not a more detailed explanation.  In fact, §3.1.1/Appendix A/§3.1.2 declare the EBBR discovery to be out of scope.  I think that declaring this part of the specification out of scope is ok, mostly because finding the path towards the source/RP is a well-known process in PIM.  The difference is that the RPF neighbor (EBBR in this case) will usually not be directly connected.

I wonder if the process can be described using "RPF", with the caveats that the RPF neighbor is the EBBR and RPF interface is the BIER tunnel towards it.

[] Suggestion -- to replace the last two paragraphs (and eliminate §3.1.1/3,1,2)>

   When a PIM Join or Prune message is received, the IBBR determines whether
   the Source or RP is reachable through the BIER domain.  The EBBR is the
   BFR through which the Source or RP is reachable.  In PIM terms [rfc7761],
   the EBBR is the RPF Neighbor, and the RPF Interface is the BIER "tunnel"
   used to reach it.  The mechanisms used to find the EBBR are outside the
   scope of this document -- some examples are provided in Appendix A.

   If the lookup results in multiple EBBRs, then the EBBR closest to the
   source should be preferred.  The selection algorithm should ensure that
   all signaling for a particular (S,G) or RP is forwarded to a single EBBR.
   For example, the selection can be round robin or use the lowest EBBR IP
   address.


249   After discovering the EBBR and its BFR-ID, the IBBR will include a
250   new PIM Join Attribute in the join/prune message as per [RFC5384].
251   Two new "BIER IBBR" attributes are defined and explained in upcoming
252   section.  The PIM Join Attribute is used on EBBR to obtain necessary
253   BIER information to build its multicast states.  In addition the IBBR
254   will change the PIM signaling packet source IP address to its BIER
255   prefix address (standard PIM procedure).  It will also keep the
256   destination address as the well known multicast IP address.  It then
257   will construct the BIER header.  The signaling packet, in this case
258   the PIM join/prune packet, is encapsulated in the BIER header and
259   transported through BIER domain to EBBR.

[] It took me a while to correlate the "a new PIM Join Attribute in the join/prune message as per [RFC5384]" with the fact that the attribute is defined in this document (not rfc5384).

Also, I am not able to find the "two new "BIER IBBR" attributes...in upcoming section".  I see that the Join Attribute can be either IPv4 or IPv6 -- is that what you meant by 2 attributes?

Suggestion (to replace the first 3 sentences)>
   After discovering the EBBR and its BFR-id, the IBBR MUST use the BIER
   Info Vector (Section 3.1.3) PIM Join Attribute [rfc5384].  The EBBR uses
   this attribute to obtain the necessary BIER information to build its
   multicast state.

   The signaling packet, in this case a PIM Join/Prune message, is
   encapsulated in the BIER Header and forwarded through the BIER domain
   to the EBBR.  The source address of the PIM packets MUST be set to
   belong to the local BFR-prefix.  The destination address MUST be set to
   ALL-PIM-ROUTERS [rfc7761].


There was an interesting suggestion on the list [1] -- I didn't see a reply.

[1] https://mailarchive.ietf.org/arch/msg/bier/58OIQ_9JbIiUWPrR_Yo7J47GMc8


261   The IBBR will track all the PIM interfaces on the attached PIM domain
262   which are interested in a certain (S,G).  It creates multicast states
263   for arriving (S,G)s from PIM domain, with incoming interface as BIER
264   "tunnel" interface and outgoing interface as the PIM domain
265   interface(s) on which PIM Join(s) were received on.

[minor] "arriving (S,G)s"  I guess you mean "arriving Join messages"...


...
288 3.1.3.  PIM Signaling packet construction at IBBR

[nit] s/at IBBR/at the IBBR


[] Let's separate the definition of the new attribute from its use.  IOW. in §3.1.3 specify the attribute (in general -- independent of the application), and use §3.1.3.1 to indicate the use and packet construction.

The title in §3.1.3 should then be: The BIER Info Vector PIM Join Attribute


290   To ensure all necessary BIER information needed by EBBR is present in
291   the BIER signaling message, a new PIM Join Attribute [RFC5384] is
292   used.  EBBR can use this attribute to build its multicast states, as
293   described in EBBR procedure section.  This new PIM join Attribute is
294   added to PIM signaling message on the IBBR.  Its format is as follow:

[minor] Note that the name of this attribute is not mentioned until §7. :-(   BTW, do you want to keep the name as "BIER Info Vector" or expand it to "BIER Information Vector"?

Suggestion>
   The BIER Info Vector PIM Join Attribute [rfc5384] is defined as follows:


296      0                   1                   2                   3
297      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
298     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
299     |F|E|    Type=tbd |     Length  |  Addr Family    | BIER info
300     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

[major] s/Type=tbd/Attr_Type
That is the name in rfc5384.


302                       Figure 2: PIM Join Attribute

304   F bit: The Transitive bit.  Specifies whether this attribute is
305   transitive or non-transitive.  MUST be set to zero.  This attribute
306   is ALWAYS non-transitive.

[] NEW>
   F-bit: Transitive Attribute, as specified in [rfc5384].  MUST be set to
   zero as this attribute is always non-transitive.


[major] What should the receiver do if the F-bit is set?


308   E bit: End-of-Attributes bit.  Specifies whether this attribute is
309   the last.  Set to zero if there are more attributes.  Set to 1 if
310   this is the last attribute.

[] NEW>
   E-bit: End of Attributes, as specified in [rfc5384].


312   Type: TBD assign by IANA.

[] NEW>
   Attr_Type: TBD


314   Length: The length in octets of the attribute value.  MUST be set to
315   the length in octets of the BIER info +1 octet to account for the
316   Address Family field.  For IPv4 AF Length = 7+1 For IPv6 AF Length =
317   19+1.

[] NEW>
   Length: length of the value field, as specified in [rfc5384].  MUST be
   set to the length of the BIER Info field + 1.  For IPv4 the length is 8,
   and 20 for IPv6.


[major] What should a receiver do if the length is not set correctly with respect to the AF?


319   Addr Family: Signaled PIM Join/Prune address family as defined in
320   [RFC7761].

[] NEW>
   Addr Family: PIM address family, as specified in [rfc7761]