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

Gyan Mishra <hayabusagsm@gmail.com> Thu, 12 May 2022 15:29 UTC

Return-Path: <hayabusagsm@gmail.com>
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 C9061C1594B6; Thu, 12 May 2022 08:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAkaqUNVo8VW; Thu, 12 May 2022 08:29:13 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57130C1594B7; Thu, 12 May 2022 08:29:08 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id x18so5204585plg.6; Thu, 12 May 2022 08:29:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G+rUOCo8suvRyyRYGLiccHSznfgmwNOON6cWhY8jtYg=; b=RaNhlEz/TaS6uYx2CddefhKS8GHZjoPjG9KYHIIb8skttFItH6A7bVSt3pWTqszp5e zW31hhvFBYojYr2QSu0T4SwQtMZe5LneGPf/vcKkuJG7tO3UAe2vhPlpPxZSjmwCUeWm bxu1bwLoZI4bIRdIHcF9OL9ebVQ+NutMSrTOl8zZrNeLj1OuwouF3mky8BuQvjUxfgIq xjQhZ5YVvpg0Ipxb+UPlczDCIDkSLpv6fTrZvK5Yepq2XmpReZpHeU4vu1xrcjYswbFS 1Nuej8S93THDjOtCoyoTMErWNAJIrfyOpHkPv2zSnTJwPn6zCdETvppMMKHKKO5JqF3H XCIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G+rUOCo8suvRyyRYGLiccHSznfgmwNOON6cWhY8jtYg=; b=GOZxfl2tU/E26/SDYfoBh6A8kN6Y44J4hr9+TY9VJWCny2GU6lC6iTy5Z0rA+gsUgg gjvxWFMZNYzfKIhDIjQyjmcQ/hz6P3YLeQSvFYLkWiYMgQI4tcDs7vbONzKhbzGyuN5D Z4ZVau+h75tsYE2CDrwpEQJvUDsHyYScrRuqEhZ34n66BvtHrLnkQ4ta5klMeQFzLmJ/ /uAaQJpIKyfAbNCaVeBGCbUv/9ojixqsNi8da0qZanvcQLC5Qi56nWp4o/lqmGxWbJw6 1543rebPy93f1Sk9nGOX1DBpLzGrc//KNGoE43++IKADtWyjPMfPQi3c5vQ7EN7K1nef jW2g==
X-Gm-Message-State: AOAM531WUNy0OYl6LVxe/ay5mTN2oRCjEr6t6CP+KnNZJhMwBQ7XFbHY uPbtrSpKAJNizHO3tEnaTrcqREpd8m7NZMDLm9yLHkzLU6w=
X-Google-Smtp-Source: ABdhPJxZbOCYo/gn8knTUZiTVkZ3Q+sya5fUgFkU4rt+8NdJHxwC2cU8b94ltSiswxscECuR37Wvu8K6UDLG/5oqZHQ=
X-Received: by 2002:a17:902:e948:b0:15e:cd79:2a1a with SMTP id b8-20020a170902e94800b0015ecd792a1amr447443pll.109.1652369347261; Thu, 12 May 2022 08:29:07 -0700 (PDT)
MIME-Version: 1.0
References: <011e01d83493$6175b310$24611930$@ndzh.com> <BL0PR05MB56524EE412C4938C8083E3BED41A9@BL0PR05MB5652.namprd05.prod.outlook.com> <BL0PR05MB56523E436FBC1353208E9A77D41A9@BL0PR05MB5652.namprd05.prod.outlook.com> <PH0PR08MB6581D4F1DE991EA916BAC91B911A9@PH0PR08MB6581.namprd08.prod.outlook.com> <BL0PR05MB5652FFCF1DAC42EC14831C50D41D9@BL0PR05MB5652.namprd05.prod.outlook.com> <CABNhwV1w7dDxFGchJtT9qb6xcjBBygOkvg42GE3ZAtSp9qg55g@mail.gmail.com> <BL0PR05MB5652ADAFC6E35C0669E321D4D4E49@BL0PR05MB5652.namprd05.prod.outlook.com> <CABNhwV3hT2-tuKm2p6zeaayHEh4nX3GzdUv8ksoggaLLuhZiCQ@mail.gmail.com> <BL0PR05MB565251B4F7D0BBA8BC8FF74FD4ED9@BL0PR05MB5652.namprd05.prod.outlook.com> <CABNhwV1UB4ys31rtLKucNPcwZu5a5d_LOpmKhEMKnkb6h2OJcg@mail.gmail.com> <BL0PR05MB565230BE319181D3E0BDAD01D4C29@BL0PR05MB5652.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB565230BE319181D3E0BDAD01D4C29@BL0PR05MB5652.namprd05.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 12 May 2022 11:28:56 -0400
Message-ID: <CABNhwV0GuhBimywuWaVg+u81LX=ZkDHBUUsXWTtCEROmakTvJA@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: BESS <bess@ietf.org>, "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "pim@ietf.org" <pim@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fb380505ded23706"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/XdSSNZH67rYbypDCzPs9_2CKPcY>
Subject: Re: [pim] [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.34
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, 12 May 2022 15:29:17 -0000

Hi Jeffrey

Responses in-line Gyan3>

On Thu, May 5, 2022 at 9:43 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Hi Gyan,
>
>
>
> Gyan2> What is the advantage of using TEA encoding as opposed to existing
> PTA RFC 6513 & RFC 6514 MVPN signaling?
>


This is about using procedures in draft-ietf-bess-bgp-multicast-controller
to set up (s,g) forwarding state in a VRF, as an alternative to BGP-MVPN.

 Gyan3> Ack.  I think a drawing of service and transport controller would
be good and how that plays into the operator deployment.  Would there  be a
corresponding draft in PCE WG for stateful PCE instantiation of the BGP
based Trees by the controller?

As described in
https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-2,
instead of ingress/egress PE figuring out the (s,g) state based on BGP-MVPN
signaling and PIM signaling (for local OIFs to CEs), they simply take
instructions from a control on what tunnel branches and which local OIFs to
use – as if an operator is configuring them statically. This allows the PEs
to be very dumb and simple.

 Gyan3>  So this is simplified MVPN signaling state paired down from RFC
6514 using same RR or eBGP mesh peering single or multi hop using
MCAST-TREE SAFI new route types defined in BGP Multicast section 2 carrying
the s,g hard state in BGP eliminating soft state, and extends the TEA
encoding defined in BGP Multicast to as well SR use cases.

>
https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00#section-2.1

          3 -  S-PMSI A-D Route for (x,g)
          4 -  Leaf A-D Route
          5 -  Source Active A-D Route
       0x43 -  S-PMSI A-D Route for C-multicast mLDP


So RT-3 4 5 are existing RT from RFC 6514 and 0x43 is a new RT introduced
in BGP multicast draft.  Does the controller draft use all 4 RTs and / or
are there any additional RT used.   That should be spelled out in the draft
all the MCAST-TREE SAFI RTs that carry over to the controller draft.  Also
if there are any additional RFC 6514 RTs that are not included in the BGP
multicast draft those should be spelled out as well.

I think the section 3.3 Replication state RT is the only additional to the
list

>From that point of view, there is no difference between “underlay” and
“overlay” and the TEA is perfect to encode that information – each “tunnel”
in the TEA is a replication branch.

Gyan3>Ack

That section does have the following that makes use of the PTA (attached to
MCAST-TREE NLRIs for programing VRF (s,g) forwarding state):



   The Replication State route may also have a PMSI Tunnel Attribute

   (PTA) attached to specify the provider tunnel while the TEA specifies

   the local PE-CE interfaces where traffic need to be sent out.  This

   not only allows provider tunnel without a binding SID (e.g., in a

   non-SR network) to be specified without explicitly listing its

   replication branches, but also allows the service controller for MVPN

   overlay state to be independent of provider tunnel setup (which could

   be from a different transport controller or even without a

   controller).

 Gyan3> Ack
   In the draft you mention how the draft applies to SR P2MP policy and it
sounds like this draft updates the PIM P2MP draft adding the new MCAST-TREE
SAFI with procedures where each tunnel in TEA is a replication branch to
instantiate the P2MP policy.  So  this draft is an alternative controller
based option to building an SR P2MP tree using MCAST-TREE SAFI and TEA
tunnel branch encoding as opposed to using Replication SID / Tree SID
solution.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-1.7


   Procedures in this document can be used for controllers to set up SR
   P2MP trees with just an additional SR P2MP tree type and
   corresponding tree identification in the Replication State route.

   If/once the SR Replication Segment is extended to bi-redirectional,
   and SR MP2MP is introduced, the same procedures in this document
   would apply to SR MP2MP as well.


Section 3.1.1 Any Encapsulation tunnel


So would this controller procedure support I am guessing RFC 4023
MPLSoGRE RFC 7510 MPLSoUDP and

RFC 8663 SR-MPLS over IP as well as SRv6?


https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-3.1.1

Maybe listing all the encapsulation tunnels supported and caveats would be good.


Section 3.1.2 talks about TEA enhancements adding load balancing tunnel sub
TLV.  Would there also be corresponding update to SR P2MP policy as far as
load balancing as load balancing can be configured by the SR policy
directly?   What is the interaction between SR P2MP policy instantiation
and the TEA encoding of the replication branches?

SR policy uses TEA already for the policy encoding

https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-17#section-2.4.4

Section 3.1.3 Segment list tunnel

So is something new being added or are we just reiterating section 2.4.4 of
SR policy draft.  If nothing is changing and we are using the same sub TLV
in SR policy section 2.4.4 maybe state that is the case.  So all the other
sub TLV listed in section 3 are all new sub TLV that would update SR policy
draft TEA encoding of sub TLVs, correct?  As the SR policy draft is the
base draft for SR policy, here with this draft we are extending the SR
policy TEA encoding with all the additional TLVs listed.

Section 3.1.7 Backup Tunnel Sub TLV

Could this apply to unicast P2P tunnel  and not just multicast P2MP tunnel
 for backup tunnel for live-live protection?

Section 3.4.2 BGP Community container

SR policy draft does not use BGP Wide communities for encoding.

So this would be something new that we would be encoding the SR P2MP policy
using BGP Wide Community new optional atoms TLV.

Could this also apply to unicast SR P2P policy as well?

What is the benefit of encoding the SR P2MP policy  in wide community
containers versus encoding as defined in SR policy draft?

https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-17

Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Thursday, April 28, 2022 12:19 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* BESS <bess@ietf.org>; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidgoli@nokia.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org;
> pim@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Please see Gyan2>
>
>
>
> On Tue, Apr 12, 2022 at 11:02 AM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net> wrote:
>
> Hi Gyan,
>
>
>
> Please see zzh2> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Friday, April 8, 2022 8:48 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* BESS <bess@ietf.org>; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidgoli@nokia.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org;
> pim@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Please see Gyan>
>
>
>
>
>
> On Tue, Apr 5, 2022 at 7:38 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> wrote:
>
> Hi Gyan,
>
>
>
> Please see zzh> below for my view.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Tuesday, March 29, 2022 10:31 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* BESS <bess@ietf.org>; Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidgoli@nokia.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org;
> pim@ietf.org
> *Subject:* Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Dear authors
>
>
>
> Can you describe in more detail the relationship and interaction between
> the two SR P2MP variants below:
>
>
>
> Defines new SAFI for SR P2MP variant
>
> https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3jKh83Sr$>
>
>
>
> zzh> draft-ietf-bess-bgp-multicast-controller (referred to as draft-bess)
> defines a SAFI and different route types of that SAFI to setup replication
> state on IP/mLDP/SR-P2MP tree nodes. One of the route types is for SR-P2MP
> purposes.
>
> Zzh2> Correction – the MCAST-TREE SAFI is defined in
> draft-ietf-bess-bgp-multicast.
>
>
>
>    Gyan> Ack
>
> Zzh> draft-hb-idr-sr-p2mp-policy (draft in this adoption call, referred to
> as draft-hb) defines a different SAFI and route types for the same SR-P2MP
> purposes.
>
>  Gyan> The adoption call draft is aligned with SR-TE policy as P2MP
> extension for simplicity for operators which I agree makes sense.
>
> Does this draft utilize all the drafts below Tree sid / Replication sid
> and SR P2MP MVPN procedures for auto discovery etc.
>
>
>
> Zzh> Both drafts are for realizing the two tree-sid drafts mentioned
> below; both can be used for draft-ietf-bess-mvpn-evpn-sr-p2mp.
>
>  Gyan> Ack
>
> Zzh> As I mentioned before, both draft-bess and draft-hb have its own
> considerations. The biggest difference is how the replication information
> is encoded in the Tunnel Encapsulation Attribute (TEA).
>
>
>
> Gyan> Ack
>
> Zzh> I can understand that the IDR/PIM/BESS WGs may decide to accept both
> ways of encoding replication information in the TEA, but I believe we
> should share SAFI and route types between the two drafts – only the TEA
> would be different.
>
>
>
> Gyan> Both the BESS and IDR adoption draft are vastly different solutions
> that have very different goals I don’t see any reason or need to have
> similarities as far as TEA or SAFI encodings or usage.  The BGP controller
> draft has a very wide scope, but also is more of an alternative approach as
> it introduces new extensibility idea of utilizing TEA and wide communities
> encoding to make the solution RFC 6513 and 6514 MVPN signaling
> independent.  That is a drastic change for scalability for operations
> traditional use of multicast X-PMSI P-Tree  leveraging the separation of
> control plane from forwarding plane with RR using traditional MVPN
> procedures.  As the ideas from the BESS draft as it builds on the BGP
> Multicast draft is to eliminate soft state tree building protocols and with
> the move towards hard state, thus the signaling paradigm change from
> traditional MVPM procedures to alternate TEA and wide community encoding.
> Am I reading that correctly as the goals of the BESS draft?
>
>
>
> Zzh2> Not really 😊
>
>  Gyan> Ok
>
> The BESS document also mentions that the solution can be used for underlay
> and overlay trees as replacement for MVPN signaling.  For underlay trees
> are you referring to GTM?  I have many more questions about the BESS draft
> and will ask in a new thread.
>
>
>
> Zzh2> draft-ietf-bess-bgp-multicast-controller was initially intended to
> build traditional IP multicast trees (w/o any VPN specifics) and mLDP
> tunnels (started in September 2017) with calculation on and signaling from
> controllers. SR-P2MP was added in -03 (July 2020) because the generic
> mechanism for IP/mLDP trees can be used for SR-P2MP as well. These can all
> be considered as underlay.
>
>     Gyan> Ack
>
> Zzh2> Overlay support – as an MVPN replacement – was added in -06
> (February 2021), but the concept is **not different** from underlay at
> all – we’re just setting up (s, g) IP multicast state in VRFs, with
> downstream nodes including remote VRFs connected by some sort of tunnels.
> That is not different from setting up state in global table at all.
>
>
>
>      Gyan2> Ack
>
>
>
>    Gyan2> What is the advantage of using TEA encoding as opposed to
> existing PTA RFC 6513 & RFC 6514 MVPN signaling?
>
> Zzh2> Thanks.
>
> Zzh2> Jeffrey
>
> Zzh> Jeffrey
>
>
>
> Defines Tree SID stitching of replication SID SR policy P2MP variant
>
> https://datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3gdi0hAB$>
>
>
>
> Replication SID
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3smIMNzh$>
>
>
>
> Defines new SR P2MP PTA using MVPN procedures
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3g-W3jH0$>
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> On Mon, Mar 28, 2022 at 3:39 PM Jeffrey (Zhaohui) Zhang <zzhang=
> 40juniper.net@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> 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 major difference between the two ways is on #3. Indeed, we could not
> reach consensus – there are two ways of encoding the TEA and each has its
> own considerations. The draft-ietf-bess way (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.
>
>
>
> I want to initiate a discussion and I can understand that WGs may
> eventually choose to allow both ways for #3. Even so, I think we should
> strive for consistent approach at least for #1 and #2 (and for that I am
> not saying that draft-ietf-bess way must be used). For example, use the
> same SAFI and route types for both ways, but use different TEA encoding
> methods.
>
>
>
> Thanks.
>
>
>
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
> *Sent:* Friday, March 25, 2022 11:34 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Susan Hares <
> shares@ndzh.com>; idr@ietf.org
> *Cc:* 'pim@ietf.org' <pim@ietf.org>; 'BESS' <bess@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]*
>
>
>
> Hi All
>
>
>
> 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.
>
>
>
> HB> yes there was discussion and there was no consensus to merge the 2
> drafts as their approach is widely different. The authors of this draft
> have kept the implementation very close to unicast BGP SR Policy for the
> segment list, which simplifies the implementation and deployment of the
> technology. As you said there seems to be two way to download this policy
> and the segment list and we can work on both.
>
> Given the solid support I don’t see why the adoption of this draft should
> be delayed because of these arguments.
>
>
>
> Thanks
>
> Hooman
>
>
>
> *From:* pim <pim-bounces@ietf.org> *On Behalf Of *Jeffrey (Zhaohui) Zhang
> *Sent:* Friday, March 25, 2022 10:47 AM
> *To:* Susan Hares <shares@ndzh.com>; idr@ietf.org
> *Cc:* 'pim@ietf.org' <pim@ietf.org>; 'BESS' <bess@ietf.org>
> *Subject:* Re: [pim] [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 <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!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCkFZJodxFk8aTGCpYg34$>
>
>
>
> 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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGazDpUZk$>
> is another way to do the same. I also explained in
> https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGW1pXg_c$>
> 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
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3t2xHmG0$>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3l4bzk3s$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email **gyan.s.mishra@verizon.com* <gyan.s.mishra@verizon.com>
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RiHtqGntIPhoemdxe2yBGpMBQILKyyj3TMv6dkbc_ucJ3OqtTJdthtFCYzd2wPtC$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Tvnc-w7uwkJv79QNGutNiQGYzxGECmu21Ktr6Gw1Vjj5GqUslaeyHwwia2jlEeSo$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*