Re: [pim] additional extensions on draft-ietf-pim-null-register-packing-06

Abhishek Chakraborty <cabhi@juniper.net> Thu, 17 December 2020 22:45 UTC

Return-Path: <cabhi@juniper.net>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906703A046A for <pim@ietfa.amsl.com>; Thu, 17 Dec 2020 14:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=BKCJCrHs; dkim=pass (1024-bit key) header.d=juniper.net header.b=c+QIngr2
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 Oz1QilcbI44K for <pim@ietfa.amsl.com>; Thu, 17 Dec 2020 14:45:27 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A053A045E for <pim@ietf.org>; Thu, 17 Dec 2020 14:45:27 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BHMj7HM009835 for <pim@ietf.org>; Thu, 17 Dec 2020 14:45:27 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=DJFpig0e8oWBpUa8HWcSkoh6mTjfVYEvxxKmhxrGDQE=; b=BKCJCrHsS2pLiCkhhCYYO+He5WGRSF5eLbYJlKaa1ZSjehotVCKZ70IRLrFl8g+13TlN 8wpzYco+gzN7XHOHsI6VDEJiDMOi958sCxx2VePLaAZv1o/32kQTPlTjKL3dmkR9FZON 6YBX11zq7L7fr9kFrNJk+z5D0pWYahdDKbldh91UntwkpSBNkUlherClM/bx3ec7DVHp NAcH8XqnCyLvF++/mnKJ3FEVxlspjy7D1G/yhsZM8WSL8NgLlpLcBDSanym4atsqlzpi wZWQotqL449VVtsZX7F7jQz4Wp8gIN8gYJJqE4pRPngFNEWaNUCxRC6YLRzlqQ/2icX9 iw==
Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2172.outbound.protection.outlook.com [104.47.56.172]) by mx0a-00273201.pphosted.com with ESMTP id 35g23v1gkr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <pim@ietf.org>; Thu, 17 Dec 2020 14:45:26 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bxTW5hfAJJo/guXAz2CYcx/kVG7Beq/3PZs66836PLQy93IcCd27ZS7C+dUY1azkombLBmaRqJmNI5XmNwIbN0Avxjp4IKdYpMcMr1B4WLzpbSItzn98mxOOfgfniYlCLKnnqKHHIF6DipPO/jYqu4PlntjdbnZbN4tGDyvHAjku9z9kgkHhpNjoQjGiBpTkJ2RlopA4vsEJHxxgrGHWmx+pLtfikrc/xG9q6J02OgTGEpd2KsuAQEb7B48CDPFEi6auRCiIpWa5y5PPJSrksVHrGCBEYgNwORUbr15nVyG0kDxDkpXnQopZh2+bv56yFFA0Zj8GwGutvFyujgUu3Q==
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=DJFpig0e8oWBpUa8HWcSkoh6mTjfVYEvxxKmhxrGDQE=; b=ATZeC4OCr25i9UWVenlKAKddji3vlysH0P4vtdpnKFZc6zDSvPvNRuEnn7ATwQeL6hRst00TAyUQJSr9vTat6v1MllSnIoVFWPl3iFVk60QUhe0fvLANW00Cm6Wc6Ste//cBwCgQGV84D9IXP75eqVLfCqSZ5gKxnAnTzyXLaJ+93agq6gEAEdZmSVI5vFD1sq7JtcldO/AzdX/JFDuHIFzgswCcbD9TF4WI8ua/UZPPMuSKCXVnnqoMuNchGc0jSrkioWGlTnGE3CW8bKACoD+jMdwaQO4dctDZlMQbnacoMxSrUvuUnPTTKROaegt4b+MHu81cGowEwYNzw+OzZg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DJFpig0e8oWBpUa8HWcSkoh6mTjfVYEvxxKmhxrGDQE=; b=c+QIngr26Bia+FHv5+AMyHRa/E2kU8L+Kvwe3s/ScyFxtUWRjf7PRJBVM90GzArgFtpIs+JRIIvcNREbxlz/GllfTM8TVMD+yA/Za8FtupvGCwXi9GLCZUh3Mz3KsigA5IDHuv1MTm0q/XdzsaX+yDj4rxhQ75Kl59Pu6lfCjBg=
Received: from BYAPR05MB5736.namprd05.prod.outlook.com (2603:10b6:a03:c9::23) by SJ0PR05MB7804.namprd05.prod.outlook.com (2603:10b6:a03:2e8::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.12; Thu, 17 Dec 2020 22:45:25 +0000
Received: from BYAPR05MB5736.namprd05.prod.outlook.com ([fe80::f0a3:34ec:8dea:2163]) by BYAPR05MB5736.namprd05.prod.outlook.com ([fe80::f0a3:34ec:8dea:2163%7]) with mapi id 15.20.3676.019; Thu, 17 Dec 2020 22:45:25 +0000
From: Abhishek Chakraborty <cabhi@juniper.net>
To: "pim@ietf.org" <pim@ietf.org>
Thread-Topic: additional extensions on draft-ietf-pim-null-register-packing-06
Thread-Index: AdbUxkx25ShSwrNoQY6WAz6iFNjBrQ==
Date: Thu, 17 Dec 2020 22:45:25 +0000
Message-ID: <BYAPR05MB57369347B4A9F2EAF07A1F6EB5C40@BYAPR05MB5736.namprd05.prod.outlook.com>
Accept-Language: en-IN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-12-17T22:45:22Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=1c0ac07a-72d8-4ceb-9d6f-c02c8d22b820; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [116.197.184.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ec002c97-f1a2-4c88-34f4-08d8a2dd71d7
x-ms-traffictypediagnostic: SJ0PR05MB7804:
x-microsoft-antispam-prvs: <SJ0PR05MB7804F9F6AF17044DAF5348CCB5C40@SJ0PR05MB7804.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: guiWtpYvE1nDjMNPepuAR2/A+/xzY4GU595+6XYqOrCMXVF7SPcoIiZaLo5WhdDMHKzxzMI5O4j7owtklnzzDOcvF5s/94/TlSJ0t/hxVCSyhPho/6B9+6Mqb06w/xaZO06DSRrmslr2ZbmiipegSI/MxYFEGmvjNcHjbwstnbX8nG2Nq8iJsyX4epUmOMx3Pa455ixxvj7QkxTxyKc5BScVmRN7UgKWKbRDUQt2oj/7cIE7+XHQZEGxx8AogL789f5j7orJtIN8n0TT4/zxRqcMvV35eAf1SgN/649rYTtYGE5vPIxgDJkJCoG37XqTqZJPDnICykN3HuDiwY37+UdAumW9tGKr+tHyhQ5VFDWX+icTruT261wPca72I4VfztT6EcAwBGLW/LDXKDq0pkThApJDNtvdR/cx3+8l0KD8C5tUSNqzYd2lmN1ghPV7sFrA8ONOLxGCtFoRwSwaVA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR05MB5736.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(39860400002)(346002)(396003)(366004)(33656002)(66946007)(186003)(86362001)(8936002)(6916009)(71200400001)(76116006)(53546011)(64756008)(9686003)(7696005)(55016002)(83380400001)(66556008)(26005)(966005)(66446008)(8676002)(66476007)(2906002)(52536014)(5660300002)(6506007)(66574015)(478600001)(316002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?qHdE7sOmypTeQMxcv22mpvwmDsrKDtAFWG8Py5H77LOZWjFkP9zHvResSPCq?= =?us-ascii?Q?pzwH5Dlj+beocbqTjoXJ1TtBs45RuCk3/wvL+lI3i8Lo/SfzNLbPaAQoc/Mi?= =?us-ascii?Q?KNRGsz/9w8wOebTB26VU+Uo1ydkcCTo/xJKQXZGz5H1pVjmE1+Sgh4xTwFOz?= =?us-ascii?Q?puYUfxh/gHLv1HbMYapAvzBzfi9Qsv+pNykJjOaz1zuLJ4KPOPzPiA5ZO2LN?= =?us-ascii?Q?pw+CySPzuIr1Z8zqSSY/AHTs2DZ9U9ey5OmyfgESkmN36+niyUM5LaKUCa9f?= =?us-ascii?Q?M88WZcZeVxkPrpY3IdY0bm31jZm37lWQO4XR5hhaj6kLufWDsDhCNrYvFdYU?= =?us-ascii?Q?b6gtAx80JmNIWj4PeSageMioMAoPnKRiB1GfGeAoygvDqLqcN1rFn7J/a0R5?= =?us-ascii?Q?S87w25VOkAvlUBOKU9WmbxEww6V3VKY1IEr+gujyji9DLAWPaMsqIGCvYGQK?= =?us-ascii?Q?3IOLEW/LTs1qUXXxWKQwBpBsZD4MG8HB/ySm1f4mHqfcICI1n8RGIc8Stbu+?= =?us-ascii?Q?wevDAIQINGv2t8fDxHO2tBFMgJhqhPvC3EAbA5TZ8kRxG1QvuwRph8UpvmMk?= =?us-ascii?Q?f0ppIMByhI4zaP5WXFiyUO4hCTwlUAuzdwM6nIWLxJsBKrBusgIS7IbWSXoc?= =?us-ascii?Q?odrPXyyyMIWEOJ19owckQIqlWUdn/OgIIQBXNyVXrVP++W7YvOoc/tmxaRoJ?= =?us-ascii?Q?ioW6F28KiAURax+UlxccqHOp9e28zfzHvSk2cGwFoeWiMjk8JLsUH9TjMTXl?= =?us-ascii?Q?7VQfs881izUimN5dYiBl507+XHkNR7mQAvEb5BchMkJ9wak1/LNWX5CGpySR?= =?us-ascii?Q?UZonpzp8DZy69xcj4HZtuPuZHz51ZMdde2U5pyrVQ47EF1w/WlY8sbA4JFbn?= =?us-ascii?Q?Ltg2MEQMKT+KEbmNo1N3sCyBhCO6AglMKXBeG7gRZThJtGL+cLh9iC8W+xxS?= =?us-ascii?Q?QNK5lE1YC8tEOrsWkymu2nSwKttQi//O9zyiRVWrfeQ=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR05MB5736.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ec002c97-f1a2-4c88-34f4-08d8a2dd71d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2020 22:45:25.3247 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZkhfK8Io50JfKah8VqPLE8cxoAy6hzRKY4fZX7I7loRdEl9EjuxyEC9Q6Nd++VMZW5l6jrvrdN2mn8g8+HGjeQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR05MB7804
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-17_14:2020-12-17, 2020-12-17 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 adultscore=0 clxscore=1015 mlxlogscore=999 lowpriorityscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 bulkscore=0 mlxscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012170147
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/3oqQk3-eg5Sr0xaDlWKAUucKOYA>
Subject: Re: [pim] additional extensions on draft-ietf-pim-null-register-packing-06
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2020 22:45:30 -0000

1.
Draft section conflicts with PIM RFC 4601 section 4.4:

draft-ietf-pim-null-register-packing-06 tells:
7.  PIM RP router version downgrade

   Consider a PIM RP router that supports PIM Register Packing and then
   downgrades to a software version which does not support PIM Register
   Packing.  The DR that sends the PIM Packed Register message will not
   get a PIM Register-Stop message back.  In such scenarios the DR MUST
   send an unpacked PIM Register and check the PIM Register-Stop to see
   if the capability bit (P-bit) for PIM Packed Register is set or not.
   If it is not set then the DR will continue sending unpacked PIM
   Register messages.

PIM RFC 4601 section 4.4 tells:
"Just before the Register-Stop Timer expires, the DR sends a Null-Register Message to the RP to allow the
RP to refresh the Register-Stop information at the DR. If the Register-Stop Timer actually
expires, the DR will resume encapsulating packets from the source to the RP."

The suggestion for the extension to send the periodic PIM Null Registers to RP with special S,G or 0.0.0.0,0.0.0.0 and monitor the packing bit in RegisterSTop addresses this conflict.
Since in this draft draft-ietf-pim-null-register-packing-06, we are going to have :
"Type, SubType:

      The new packed Null-Register Type and SubType values TBD."

It's better to always send a previous version of Null Register and check the P bit in RegisterStop from RP.

2.
Also we may need to mention in the draft that what happens when FHR doesn't receive any one of the S,G in the RegisterStop that it received from RP as a response to its packed Null Register.
For example:
Null Register has s1,g1, s2,g2, s3,g3 and RegisterStop has s1,g1, and s2,g2.
Then it should start encapsulating for s3,g3.

3.
Also, there are use cases where FHRs can be on a LAN.
Lets say FHR1 and FHR2 is on LAN, FHR1 is the DR and it becomes the forwarder. But FHR2 is the unicast best path towards source and thus RP sends SPT to FHR2.
So, FHR1 will have Register States and FHR2 will have Forwarding states.
Lets FHR1 and RP has the capability but FHR2 does not. When FHR1 goes down, FHR2 takes up DR role and sends Null Registers to RP one by one. On RP it should fall back to older version of RegisterStop.
This is basically an FHR downgrade use case.

Thanks and Regards,
Abhishek



Juniper Business Use Only

-----Original Message-----
From: pim <pim-bounces@ietf.org> On Behalf Of pim-request@ietf.org
Sent: Thursday, December 17, 2020 4:11 PM
To: pim@ietf.org
Subject: pim Digest, Vol 200, Issue 11

[External Email. Be cautious of content]


Send pim mailing list submissions to
        pim@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iEdjVwZ_k$
or, via email, send a message with subject or body 'help' to
        pim-request@ietf.org

You can reach the person managing the list at
        pim-owner@ietf.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of pim digest..."


Today's Topics:

   1. review of draft-ietf-pim-null-register-packing-06
      (Leonard Giuliano)
   2. A additional extensions on
      draft-ietf-pim-null-register-packing-06 (Abhishek Chakraborty)


----------------------------------------------------------------------

Message: 1
Date: Wed, 16 Dec 2020 12:54:52 -0800
From: Leonard Giuliano <lenny@juniper.net>
To: <pim@ietf.org>
Subject: [pim] review of draft-ietf-pim-null-register-packing-06
Message-ID: <85e5560-ec0-d98-dcbc-68ae3391248@juniper.net>
Content-Type: text/plain; format=flowed; charset="US-ASCII"


I reviewed the Null-Register packing draft and found it to be a well-written, concise and clear doc specifying a very simple optimization.
Very much appreciate the brevity of this doc.  A few very minor (mostly
editorial) nits, plus one question:

-sect2, 1st para, last sentence: "when it learns RP is capable"
        -learns the RP

-sect8, last sentence: "the number of records should be limited to the MTU of the outgoing interface."
        -might be more appropriate to say "limited by the MTU"

-sect9, 2nd para, last sentence: "these messages are not required for PIM-SSM."
        -'required' implies they could be optionally used in SSM, so it might be better to say "these messages are not used in PIM-SSM."

-sect9, 3rd para, 1st sentence: "case where a spoof Register can be sent"
        -"spoofed Register message"


-sect9, 3rd para, 2nd sentence: "This can cause Null-Registers to not be received by the RP."
        -might be better to say "This can cause packed Null-Registers to be sent to an RP that doesnt support this packed format."

-sect9, 3rd para, 3rd sentence: consider revising this sentence.  Maybe something like "For example, uRPF can be used to filter spoofed packets."

-Sect6: this recommendation seems equally applicable to Anycast RP with MSDP for the same reasons as it is being recommended for Anycast RP with PIM.

Substantive question: could there ever be a case where an RP might need to send Register-stops for only a subset of the s-g pairs that were in the packet null-register message?  I couldn't think of a reason, but thought I'd ask.

-Lenny



------------------------------

Message: 2
Date: Thu, 17 Dec 2020 10:40:59 +0000
From: Abhishek Chakraborty <cabhi@juniper.net>
To: "pim@ietf.org" <pim@ietf.org>
Subject: [pim] A additional extensions on
        draft-ietf-pim-null-register-packing-06
Message-ID:
        <BYAPR05MB5736B21B11E094D289068FB1B5C40@BYAPR05MB5736.namprd05.prod.outlook.com>

Content-Type: text/plain; charset="us-ascii"

Hi Experts,

Going through the below draft, I felt we extend the same to address a heterogeneous networks (in terms of having mix of capable/non-capable RPs):

https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-pim-null-register-packing-06__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iEZ0v0shs$


What the draft says:

"   To ensure compatibility with routers that do not support processing
   of the packed format, A router (DR) can decide to pack multiple Null-
   Register messages based on the capability received from the RP as
   part of Register-Stop.  Thus a DR will switch to the packed format
   only when it learns RP is capable of handling the packed Null-
   Register messages.
"

I would like to suggest 2 new extensions in the draft:

  1.  Once a router becomes an FHR (once data traffic hits), it uses the above mechanism to find out if the RP supports packing capability or not from RP's first RegisterStop. Later on, before sending packed NULL Registers:
     *   FHR to send a NULL Register packet to respective RPs for different group ranges, with either Group, Source 0.0.0.0, 0.0.0.0 or with a reserved Multicast group, and wait for a RegisterStop to ensure the RP still supports decoding of packed NULL Registers. So every 60 secs before sending packed Registers, we need to be sure the RP still supports this capability.
  2.  For BootStrap use cases,
     *   Candidate RP can advertise the capability bit to the BSR in the reserved bit of RFC 5059 section 4.2.
     *   The BSR can then map the best RP to its group range and can send the BSM to all the routers enabling the capability bit of each RP in the reserved bits in RFC 5059 section 4.1.
     *   When the rest of the Non RPs get the BSM, it can know in advance which RP supports capability and which doesn't.

Advantages with the above extensions:

  1.  With above 1.a extension in the draft we can now support mix of capable/non-capable RPs in a network. This extension also addresses the dynamic upgrade/downgrade of a router in a network. Also this allows us to have a heterogeneous RP sets in Anycast RP cases (Anycast RP with MSDP and not PIM Anycast RP sets). For example:
     *   RP1 and RP2 are anycast RPs in network. RP1 is primary and RP2 is secondary in terms of best unicast reachability.
     *   RP1 supports packing capability and RP2 doesn't.
     *   FHR sends packed Null Registers to RP1 initially.
     *   Now RP1 goes down as some link in between flapped.
     *   FHR unaware of this churn. The tunnel is same for FHR.
     *   Now if FHR continues to send packed NULL registers to RP2 it breaks.
     *   So the 1.a extension (sending that extra reserved group register to RP2 before sending periodic NULL register) will make sure that RP2 is capable or not.
  2.  The BSR extension in above 2.a and 2.b let the non RPs in the network know the capabilities of the RPs.

Please let me know your views on the above extensions.

Thanks and Regards,
Abhishek



Juniper Business Use Only
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/pim/attachments/20201217/bbb35362/attachment.htm__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iE-nRgYP0$ >

------------------------------

Subject: Digest Footer

_______________________________________________
pim mailing list
pim@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iEdjVwZ_k$


------------------------------

End of pim Digest, Vol 200, Issue 11
************************************