Re: [pim] Call for adoption: draft-voyer-pim-sr-p2mp-policy-00

Rishabh Parekh <rishabhp@gmail.com> Wed, 22 January 2020 00:45 UTC

Return-Path: <rishabhp@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 0AD061200C4 for <pim@ietfa.amsl.com>; Tue, 21 Jan 2020 16:45:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6CHw0pPbK0F for <pim@ietfa.amsl.com>; Tue, 21 Jan 2020 16:45:34 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 382E01200C3 for <pim@ietf.org>; Tue, 21 Jan 2020 16:45:34 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id g17so5499509wro.2 for <pim@ietf.org>; Tue, 21 Jan 2020 16:45:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XajqUqI3NHKvNYANpsfSESUVMX9lZ9GxLqZoKLNZWog=; b=iK9wGJr7ALG6hRyxTooPMjWHGSSsD0Ss/Um2fUMPuX0QoOMQ4VUo/a7qMtmVhJLGcY rTfWnreGCsA3sJdxO4CeAJyVHqTGWvW9+RFt3ThFFtcbFCwzB9aIpHVE/3lh9qniN+l8 3KwVMjawQZZqvjOdxiG1lx/vm/Bs9H8+O7o5AHXCUrYvu9XVGJpvqYGMt7L49Xc8cdtG 0Njdi0u+PnDG/PPZlWZK2xI5dfYaNRm3vd16ynlTo3alQu18LJqTuM30AXEEvVJl1Us4 Hb7nVdvCTmMDZbIvSsu9f0h9HgysTfWEFqEiZy+zskj9M2iWMoBRvTgANylpnq4AhlaG hv4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XajqUqI3NHKvNYANpsfSESUVMX9lZ9GxLqZoKLNZWog=; b=gP0HbKTZr8PSMdFFqoMMt6yV8zJZ82eaMW8t07ImxQw+MG3n21JV+uUi1Iq3zHQMu1 fsp6YW+Uvltj3u1fOW1Hjc9586bw87Cq4MTkEZlWbiArcf3RqgsXc4Ay47M0TjL9FpVs kIRV+MwTQ7UPLTSXX7GZsHyAAdT982fNoX8OXu7dijBW0Rsgez9XzN1BH7EOM/vLV4g+ GKHSbBSZmSapsU6GV98zeQYmU1UcZ3sTuB4ZnAn2IwWaSDPXbitlsBWgqoUhRo/OgIOo 7KD3D8rbyUnyvlLwYrmeLlGgY80Oc2m60UVfRl/95OG8sbUcE5r0RpDqcKNkVnJPtSIq R4QQ==
X-Gm-Message-State: APjAAAVzV0W0fJuLRhDTqIECG1dgWxwLOKiv+WyPTZlMVikkw0xv6GL4 iiyAfEq69mrchd2N89LkyXAv+6+v6hwYvkBe/Ek=
X-Google-Smtp-Source: APXvYqw4T0whGVGWp7wmetYBWHtyWL6mFESTssCoQ+AXilqIpuDvgPdanEmP6Tmk0bbxDr1MKhB9Ghxzxx0mdVUUOEg=
X-Received: by 2002:adf:ec0d:: with SMTP id x13mr7768407wrn.400.1579653932589; Tue, 21 Jan 2020 16:45:32 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR13MB2807975CA111DEBE6B34255DF4340@BYAPR13MB2807.namprd13.prod.outlook.com> <AM0PR07MB5347669BCBA4A407283573559A320@AM0PR07MB5347.eurprd07.prod.outlook.com> <CABNhwV1AjiV6mLAhRSWFo=Ufb88R5Xtxnw6vvVw0Er8npmtQgQ@mail.gmail.com> <CABjMoXasy-YDZwg=OgJgqh2rZgDpDy0H7mwywn6+LpjKsoWbug@mail.gmail.com> <CABNhwV0OaE_Nnk1NkR0cfs8FeT+PqsLC-XZvMSpQy1EOpOU77A@mail.gmail.com>
In-Reply-To: <CABNhwV0OaE_Nnk1NkR0cfs8FeT+PqsLC-XZvMSpQy1EOpOU77A@mail.gmail.com>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Tue, 21 Jan 2020 16:45:21 -0800
Message-ID: <CABjMoXatfKKx5d9XZ5--=6tefQOzc-HBiL6bFj-98Qg1MAv6_w@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: "pim@ietf.org" <pim@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/d4ALLguUZTuTs87KO4wwWaebWNI>
Subject: Re: [pim] Call for adoption: draft-voyer-pim-sr-p2mp-policy-00
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: Wed, 22 Jan 2020 00:45:37 -0000

Gyan>I believe the main goal of this draft is introducing the P2MP MDT
instantiation root Tree-SID and leaf replication-SID over SR-MPLS.  Is
this the first draft that introduces these two new SIDs for multicast?

To be precise, this draft is about building a tree by stitching
Replication Segments (see draft-voyer-spring-sr-replication-segment)
using a PCE. Tree-SID is just a special case where the
Replication-SIDs of all the Replicatoin Segments of the tree are
identical. Effectively, there is only one new SID, the Replication-SID
and that is defined by the Replicatoin Segment draft.


Gyan> Distributed tree building protocols over SR-MPLS would also use
the same MVPN procedures in RFC 6513 and 6514 ; however for P2MP trees
to be instantiation they would need the root tree-sid and leaf
replication-sid and use of binding sid for Gyan> SR policy to steer
traffic into the P2MP p-tree as described in this draft.    What is
sister draft if it exists that talks about this very topic of  SR-MPLS
P2MP p-tree instantiation using tree-sid and replication-sid in a
distributed or hybrid model?

I am not sure I understand your question completely, but let me try to
answer. Think of Tree-SID as an alternate option to PIM, mLDP, RSVP-TE
P2MP and IR. You don't need Tree-SID to use these distributed
protocols in SR domain; if desired they can run as "ships in the
night" with unicast SR.

Gyan> From the MVPN draft appears all the MVPN procedures are the same
for P2MP tree instantiation over SR using the new tree-sid and
replication-sid.  As far as the p-tree tunnel id  types that would be
supported I am guessing only IR (ingress Gyan> replication) and all
the PIM trees for Rosen tunnels.  Anything RSVP TE or mLDP based would
not be supported.

Again, I don't unsderstand the above text. I hope my earlier response
about Tree-SID being a distinct (and stand alone) opton to other
P-Tree distributed technologies is suffciently clear to address the
above.

Gyan>I am guessing PIM Birdir c-multicast over p-tree would not be
supported since MP2MP would now not be possible over SR due to lack of
mLDP MP2MP LSP.  Im

Not necessarily. For example, some concepts from RFC 7740 (Simulting
MP2MP using IR) can be used, but we will have to look at the details.

Gyan>As far as MVPN since mostly there is no change for instantiation
of trees are the route types numbering 1-7 am guessing stays the same.
Not sure if that is vendor specific with the MVPN route type
numbering.

Yes, MVPN route types remain unchanged. A new Tunnel Type for Tree-SID
is defined in PMSI Tunnel Attribute.

Gyan>Would BIER (bit indexes replication) for stateless trees be
supported with this draft or future updates?  I believe BIER supports
MP2MP MDT trees so If SR supports BIER then that could provide support
for MP2MP.

BIER is an orthogonal discussion wrt to this draft. It is a distinct
P-Tree technology by itself and therefore not needed to be addressed
in this draft.

-Rishabh

On Tue, Jan 21, 2020 at 2:53 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>
> Hi Rishabh
>
> Response in-line
>
> Kind regards
>
> Gyan
>
> On Tue, Jan 21, 2020 at 1:31 PM Rishabh Parekh <rishabhp@gmail.com> wrote:
>>
>> Gyan,
>>
>> >This draft documents the data plane aspects of instantiation of P2MP trees for ASM and SSM or MP2MP for PIM Birdir over SR-MPLS via centralized PCE controller. Does this model support distributed and hybrid models of tree instantiation.  That is not >mentioned in the draft.  Please point out where mentioned if it is so.  If this draft does not support hybrid or distributed instantiation please explain why.
>>
>> This draft do not cover distributed tree building protocols since
>> these are already specified for both IP and MPLS.
>
>
>     Gyan>I believe the main goal of this draft is introducing the P2MP MDT instantiation root Tree-SID and leaf replication-SID over SR-MPLS.  Is this the first draft that introduces these two new SIDs for multicast?
>
> Gyan> Distributed tree building protocols over SR-MPLS would also use the same MVPN procedures in RFC 6513 and 6514 ; however for P2MP trees to be instantiation they would need the root tree-sid and leaf replication-sid and use of binding sid for SR policy to steer traffic into the P2MP p-tree as described in this draft.    What is sister draft if it exists that talks about this very topic of  SR-MPLS P2MP p-tree instantiation using tree-sid and replication-sid in a  distributed or hybrid model?
>
>>
>> >The document mentions SR but does not state SR-MPLS.  There are two flavors of SR via SR-MPLS reusing MPLS dataplane or SRv6 using IPv6 dataplane.
>> >I am guessing SRv6 MDT instantiation is out of scope of this document which should be mentioned
>>
>> Trees using SRv6 data plane can also be instantiated using SR-PCE,
>> similar to SR-MPLS. This would be added in future revision of the doc.
>>
>> >Does this draft use reuse the MVPN procedures defined in RFC 6513 and 6514 instantiation of UI-PMSI MI-PMSI inclusive Default MDT and S-PMSI selective Data MDT.  In the draft I don’t see mention of reuse of the BGP MVPN procedures.
>>
>> This draft is just for tree instantiation.
>> draft-parekh-bess-mvpn-sr-p2mp-01 documents use of such trees for
>> MVPN.
>
>
>  Gyan>  From the MVPN draft appears all the MVPN procedures are the same for P2MP tree instantiation over SR using the new tree-sid and replication-sid.  As far as the p-tree tunnel id  types that would be supported I am guessing only IR (ingress replication)
> and all the PIM trees for Rosen tunnels.  Anything RSVP TE or mLDP based would not be supported.  I am guessing PIM Birdir c-multicast over p-tree would not be supported since MP2MP would now not be possible over SR due to lack of mLDP MP2MP LSP.  Im
>
> Gyan>As far as MVPN since mostly there is no change for instantiation of trees are the route types numbering 1-7 am guessing stays the same.  Not sure if that is vendor specific with the MVPN route type numbering.
>
> Gyan>Would BIER (bit indexes replication) for stateless trees be supported with this draft or future updates?  I believe BIER supports MP2MP MDT trees so If SR supports BIER then that could provide support for MP2MP.
>>
>>
>>
>> >This document does not talk about fast reroute of MDT in the context of SR-MPLS SR-TE
>>
>> There is a brief mention of FRR in Section 4.4.1
>>
>> Gyan>With FRR I see 1:1  backup  but would facility backup be supported N:1 .  Since SR-MPLS reused the ldp data plane with label stack traffic steering I think N:1 facility backup is still relevant. There maybe a future separate draft  on SR-TE P2P LSP unicast protection and P2MP MDT tree protection.
>>
>>
>> Thanks,
>>
>> -Rishabh
>>
>>
>>
>>
>> On Mon, Jan 20, 2020 at 3:18 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>> >
>> >
>> > Authors
>> >
>> > I support but do have a few comments and questions on the draft below.
>> >
>> > This draft documents the data plane aspects of instantiation of P2MP trees for ASM and SSM or MP2MP for PIM Birdir over SR-MPLS via centralized PCE controller. Does this model support distributed and hybrid models of tree instantiation.  That is not mentioned in the draft.  Please point out where mentioned if it is so.  If this draft does not support hybrid or distributed instantiation please explain why.
>> >
>> > The document mentions SR but does not state SR-MPLS.  There are two flavors of SR via SR-MPLS reusing MPLS dataplane or SRv6 using IPv6 dataplane.
>> >
>> > I am guessing SRv6 MDT instantiation is out of scope of this document which should be mentioned.
>> >
>> > Does this draft use reuse the MVPN procedures defined in RFC 6513 and 6514 instantiation of UI-PMSI MI-PMSI inclusive Default MDT and S-PMSI selective Data MDT.  In the draft I don’t see mention of reuse of the BGP MVPN procedures.
>> >
>> > This document does not talk about fast reroute of MDT in the context of SR-MPLS SR-TE.
>> >
>> >
>> > Kind regards
>> >
>> > Gyan
>> >
>> > On Mon, Jan 20, 2020 at 6:03 PM Mehta, Dhaval (Nokia - US/Mountain View) <dhaval.mehta@nokia.com> wrote:
>> >>
>> >> I support.
>> >>
>> >>
>> >>
>> >> Thank you,
>> >>
>> >> Dhaval
>> >>
>> >>
>> >>
>> >> From: pim <pim-bounces@ietf.org> On Behalf Of Michael McBride
>> >> Sent: Monday, January 13, 2020 4:25 PM
>> >> To: pim@ietf.org
>> >> Subject: [pim] Call for adoption: draft-voyer-pim-sr-p2mp-policy-00
>> >>
>> >>
>> >>
>> >> Happy New Year PIMers,
>> >>
>> >>
>> >>
>> >> Today begins a two week call for adoption of draft-voyer-pim-sr-p2mp-policy-00 involving p2mp tree construction in a segment routing domain.
>> >>
>> >>
>> >>
>> >> This draft has been presented in our face to face meetings, including most recently in Singapore, and the authors have asked for a call for adoption.
>> >>
>> >>
>> >>
>> >> https://tools.ietf.org/html/draft-voyer-pim-sr-p2mp-policy-00
>> >>
>> >>
>> >>
>> >> Please read the draft and let the wg know if you think it’s ready, or not, for adoption.
>> >>
>> >>
>> >>
>> >> thanks,
>> >>
>> >> mike
>> >>
>> >> _______________________________________________
>> >> pim mailing list
>> >> pim@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/pim
>> >
>> > --
>> >
>> > Gyan  Mishra
>> >
>> > Network Engineering & Technology
>> >
>> > Verizon
>> >
>> > Silver Spring, MD 20904
>> >
>> > Phone: 301 502-1347
>> >
>> > Email: gyan.s.mishra@verizon.com
>> >
>> >
>> >
>> > _______________________________________________
>> > pim mailing list
>> > pim@ietf.org
>> > https://www.ietf.org/mailman/listinfo/pim
>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: 301 502-1347
>
> Email: gyan.s.mishra@verizon.com
>
>
>