Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call - TEA attribute
Susan Hares <shares@ndzh.com> Wed, 06 April 2022 00:04 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 DD4783A1723 for <idr@ietfa.amsl.com>; Tue, 5 Apr 2022 17:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.04
X-Spam-Level: *
X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 pIsnZCiY8Du6 for <idr@ietfa.amsl.com>; Tue, 5 Apr 2022 17:03:58 -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 485E03A1716 for <idr@ietf.org>; Tue, 5 Apr 2022 17:03:58 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.107.98.107;
From: Susan Hares <shares@ndzh.com>
To: idr@ietf.org
Date: Tue, 05 Apr 2022 20:03:52 -0400
Message-ID: <012001d84949$ccebb7f0$66c327d0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0121_01D84928.45E0CEB0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdhJQAVq545WacCQQv6zJfGNgTmswA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZEM-7YgtgSXZS_bIAa5OLXaGsps>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call - TEA attribute
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: Wed, 06 Apr 2022 00:04:03 -0000
Jeffrey and Hooman: This adoption call runs until 4/8/2022. The reason I have extended the adoption call is to determine what interaction there is between draft-hb-idr-sr-p2mp-policy-04.txt (which has interest in IDR) and draft-ietf-bess-bgp-multicast-controller-07.txt (adopted by BESS). I need your input on these questions in order to advise BESS, PIM, and IDR WG-chairs + WGS on the status of these drafts. Please let me know if I am Unclear on my questions. This is the first of 3 lengthy technical messages. You indicated in https://mailarchive.ietf.org/arch/msg/idr/8k4Pkcg0aqIwPFbSULXepsaHDSw/ "When it comes to SR-P2MP state downloading, there are three aspects involved here: 1. NLRI to encode policy information 2. NLRI to encode <tree/path/instance, node> identification 3. Tunnel Encapsulation Attribute (TEA) that encodes actual replication branches The draft-ietf-bess-(even when used for SR-P2MP) is aligned with other non-SR multicast trees (IP/mLDP) for a unified approach, while draft-hb is aligned to unicast BGP SR policy." This post examines the TEA attribute discussion in section 3.1 of draft-ietf-bess-bgp-multicast-controller-07.txt draft. Section 3.1 specifies two types of tunnels for TEA (RFC9012): any encapsulation (3.1.1) and load balancing (3.1.2) plus interactions with PMSI (section 3.1.3), and 4 Sub-TLVs. In section 3.4.3 you provide signaling for the Policy to enter this tree, but you do not indicate how the two different tunnel types interact with the tunnel types defined in draft-ietf-idr-segment-routing-te-policy-15.txt Section 2.4.4 of draft-ietf-idr-segment-routing-te-policy-15.txt contains a new tunnel type: SR Policy and two groups of subTLVs: weight SubTLV and segment SubTLVS (A-K). 1) how do the 3 Tunnel types interact? (all encapsulation, load balancing, and SR Policy type) Please include in your discussion where this interaction is Described in the text. 2) How do these 3 tunnel types interact with the PMSI tunnels or Source-Active AD routes (types 1-3), or ASM SPT (type 5) or C-multicast overlays (Type 6-7)? This is (section 3.1.3)? 3) draft-bess-bgp-multicast-controller states in section 1.7 on sr-p2mp: "An SR- Point-to-Multipoint (SR P2MP) policy is used to Define and instantiate a P2MP tree which is computed by a Controller." Section 3.4.2 defines the SR P2MP policy as BGP Community container in the BGP Wide communities which Contains candidate path preference + TLVS. You state in section 3.4.2 "The replicate state route for replication segments signaled to the root is also used to signal (parts of) the SR P2MP Policy - the policy name, the set of leaves [..optional], the preference of CP and other information". 3a) Are you proposing translating this from the SR Policy or what? 3b) how are the atoms used in the policy? 4) Give an example of how a simple scenario might be implemented With section 3.4.3.1 and 3.4.3.2? Thank you, Sue From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Friday, March 25, 2022 10:47 AM To: Susan Hares; idr@ietf.org Cc: 'BESS'; 'pim@ietf.org' Subject: RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call [+ BESS, PIM] Hi, I realized that in a hurry I did not respond to the specific questions below. Please see zzh> next to the questions. Looks like that there are some comments on BESS/PIM list and I will go through those to see if I have any addition/follow-up on those. Juniper Business Use Only From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey (Zhaohui) Zhang Sent: Friday, March 25, 2022 6:30 AM To: Susan Hares <shares@ndzh.com>; idr@ietf.org Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call [External Email. Be cautious of content] I am sorry for responding late. I somehow missed this. I think we should discuss the relationship with daft-ietf-bess-bgp-multicast-controller further before adopting this. Thanks. Jeffrey Juniper Business Use Only From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares Sent: Thursday, March 10, 2022 10:28 AM To: idr@ietf.org Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call [External Email. Be cautious of content] IDR WG: If you just wish to respond to the IDR list, you may respond to this email on the adoption call. Cheers, Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, March 10, 2022 9:55 AM To: idr@ietf.org; 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/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hb-idr-sr -p2mp-policy/__;!!NEt6yMaO-gk!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCk FZJodxFk8aTGCpYg34$> In your comments for this call please consider: Zzh> I want to point out that https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/ is another way to do the same. I also explained in https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/ why it was in the bess WG. Zzh> In addition, the bess draft supports *other* multicast trees (IP, mLDP besides SR-P2MP) using a consistent way. 1) Does this technology support the SR P2MP features that distributes candidate paths which connect a multicast distribution tree (tree to leaves). Zzh> It is one way to use BGP to support that. The bess draft specifies another way. 2) Is the technology correctly specified for the NLRI (AFI/SAFI) and the tunnel encapsulation attribute additions (sections 2 and 3)? Zzh> The specified SAFI and tunnel encapsulation attribute additions are one way for the BGP signaling for SR-P2MP. The bess draft specifies another way. 3) Does the P2MP policy operation (section 4) provide enough information for those implementing this technology and those deploying the technology? 4) Do you think this multicast technology is a good Place to start for P2MP policy advertisement via BGP? Zzh> Both ways are good place to start. We just need to figure out how to proceed with the two proposals. 5) Do you think this SR P2MP policies should not be advertised via BGP? Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to discuss the two ways and figure out how to proceed. The authors have discussed before though we have not reached consensus. Zzh> Thanks! Zzh> Jeffrey Cheers, Susan Hares
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Susan Hares
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Jeffrey (Zhaohui) Zhang
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Jeffrey (Zhaohui) Zhang
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Jeffrey (Zhaohui) Zhang
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Jeffrey (Zhaohui) Zhang
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Susan Hares
- Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/… Susan Hares