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

Susan Hares <shares@ndzh.com> Tue, 22 March 2022 11:33 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154CF3A111C for <idr@ietfa.amsl.com>; Tue, 22 Mar 2022 04:33:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.125
X-Spam-Level: *
X-Spam-Status: No, score=1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.186, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 FZGzO0HMXvyi for <idr@ietfa.amsl.com>; Tue, 22 Mar 2022 04:33:16 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 BFCDA3A111A for <idr@ietf.org>; Tue, 22 Mar 2022 04:33:15 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.107.114.225;
From: Susan Hares <shares@ndzh.com>
To: "'Swadesh Agrawal (swaagraw)'" <swaagraw@cisco.com>, idr@ietf.org
References: <011e01d83493$6175b310$24611930$@ndzh.com> <95EBA2ED-63CD-4335-A873-227FE85F44EF@cisco.com>
In-Reply-To: <95EBA2ED-63CD-4335-A873-227FE85F44EF@cisco.com>
Date: Tue, 22 Mar 2022 07:33:01 -0400
Message-ID: <033b01d83de0$99456460$cbd02d20$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_033C_01D83DBF.12363560"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGp/yvwH9nW5W2IuizwYX5ak4V6dQH8bkA+rRffNhA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/7wuTQPGXrKyD7cfqYhubJoi7OVM>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2022 11:33:21 -0000

Swadesh:

 

Thank you your clear responses to my questions. 

 

Sue 

 

From: Swadesh Agrawal (swaagraw) [mailto:swaagraw@cisco.com] 
Sent: Monday, March 21, 2022 6:03 PM
To: Susan Hares; idr@ietf.org
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

 

Hi Sue,

 

I support adoption of the draft.  Below is the response for specific consideration asked for each point:

 

1.      On lines similar to SR policy advertisement in BGP, draft extends BGP procedures to download SR P2MP policy and reuses the concept of a candidate path. It supports P2MP policy route, replication segment route and OIFs route of replication segment to create multicast distribution tree.
2.      Yes its defined correctly with different route types advertising tree information. Below are the important aspects
a.      Procedures avoid downloading all OIFs in single BGP route, hence avoiding complex TEA attribute.

b.	Individual OIF can be added, modified and withdrawn. No complete tree download each time.

c.       BGP packing efficient allowing distinct trees replication segments and OIFs packed in single update.
3.      Route types provide 
a.      P2MP tree information to head end
b.      Replication segment information to replication node
c.       OIF information
4.      Any deployment which uses BGP advertisement for P2P SR policy should have similar procedures to download P2MP trees from controller. SO yes, such procedures are required.
5.      No, due to reasons stated in point 4.
 
Regards
Swadesh

 

 

From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
Date: Thursday, March 10, 2022 at 7:29 AM
To: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

 

IDR WG: 

 

If you just wish to respond to the IDR list, 

you may respond to this email on the adoption call. 

 

Cheers, Sue 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 9:55 AM
To: idr@ietf.org; pim@ietf.org; bess@ietf.org
Subject: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

 

This begins a 2 week WG adoption call for: 

draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022) 

 

You can obtain the draft at: 

https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/

 

In your comments for this call please consider: 

 

1)  Does this technology support the SR P2MP features 

that distributes candidate paths which connect 

a multicast distribution tree (tree to leaves). 

 

2) Is the technology correctly specified for the 

NLRI (AFI/SAFI) and the tunnel encapsulation attribute 

additions (sections 2 and 3)? 

 

3) Does the P2MP policy operation (section 4) 

provide enough information for those implementing this 

technology and those deploying the technology? 

 

4) Do you think this multicast technology is a good

Place to start for P2MP policy advertisement via BGP? 

 

5) Do you think this SR P2MP policies should not be advertised 

via BGP? 

 

Cheers, Susan Hares