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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 22 January 2020 06:30 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 6081C120048 for <pim@ietfa.amsl.com>; Tue, 21 Jan 2020 22:30:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 7levjyG-jNNM for <pim@ietfa.amsl.com>; Tue, 21 Jan 2020 22:30:01 -0800 (PST)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 D7298120013 for <pim@ietf.org>; Tue, 21 Jan 2020 22:30:00 -0800 (PST)
Received: by mail-lj1-x231.google.com with SMTP id o13so5484327ljg.4 for <pim@ietf.org>; Tue, 21 Jan 2020 22:30:00 -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; bh=5XMuDoUpVDs/GnPdmccehT0QDMI32eiZGH617SrEbhI=; b=OHGi128RNv6+TMdD2NaXO2DUhV4b/XZzaxY63TuUpe/p7nZp/1zEmDoz1fP2Oykz6c wLt9i11uCjfqp5nOAXzj0p2pQvqxQQZs0naKcrDeUDingnCfn3O6IncmjWUprUSm1pv9 a5BCmvYHVwAuaKABE9JEQtNt+WDH3+oBsOpazbV0enPKynPuvNZI+hlvnJyXVvVhZfHX 4HdsM8iCuVEDw/6TCCgzPhGIeTkW5z8lNlDxRdGRknzBUxAopCDCDSkJlaMW9dFT+Hh1 oG3iqh/+oMkt97zZKDxfQP6Ft+LLRui9/tpqlsQWC6/YsWmMeV/6dLO0scNV8SKu3hg2 qhmg==
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; bh=5XMuDoUpVDs/GnPdmccehT0QDMI32eiZGH617SrEbhI=; b=TKOlbEDARUjlr2JeDxeQF9+au4I2r2ZQiEIrE9gWJr3A1IsNQTjq2ZP1thXRaSOnRb Ywl+Hn97s6Aw4VYjCrsy/pGcQwv3pXh/xkqRMC5jxJKJlQPDg/s9Jqjl22mDQkvuqSwa vKDxCiucbkq8sAZKL6/UaiC9vDveo4MAo415A8FyHMjnUKzST5au3liS8J0/Y2iCKL4b qmcrD7Z26MOe7/T9624RrobclSp/lIm1ZkPLryh73wjMp3nXrQ+2pkcCDEJNkJ016pRg NNrsQf9+LnqSZ04pJZoDnCX1KMs3QWHBIWKl6s4I7RPdjjBZYbOUag1t8cvgU7KKWy+T x8LA==
X-Gm-Message-State: APjAAAXChtyZc8rqc7dSck09I5tpcEj0mpnMj04kSeemOjw8TE4ojqoE xGeDp4goCxTqAcrVApkcbuiztadkt3I8GfdHYIA=
X-Google-Smtp-Source: APXvYqyNSH20DdbV3nwEMEkZKAaxWocGOTgSUqp0tKX11ETtKwNg6+UhapfiYyvHZZO/7LTk5ZiShFLup7SLPtiM+3I=
X-Received: by 2002:a05:651c:32b:: with SMTP id b11mr4344836ljp.203.1579674598984; Tue, 21 Jan 2020 22:29:58 -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> <CABjMoXatfKKx5d9XZ5--=6tefQOzc-HBiL6bFj-98Qg1MAv6_w@mail.gmail.com>
In-Reply-To: <CABjMoXatfKKx5d9XZ5--=6tefQOzc-HBiL6bFj-98Qg1MAv6_w@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 22 Jan 2020 01:29:47 -0500
Message-ID: <CABNhwV2amqjBLTcmsbtufpA5YVnyx_9_dydYAjcYeOSzYvpFVg@mail.gmail.com>
To: Rishabh Parekh <rishabhp@gmail.com>
Cc: "pim@ietf.org" <pim@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000554f20059cb4a79c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/wjN2kcbzA2OV4T0IDuwzqVIWg7U>
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 06:30:05 -0000

On Tue, Jan 21, 2020 at 7:45 PM Rishabh Parekh <rishabhp@gmail.com> wrote:

> 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>. Understood.  The replication-SID allows for stitching all the
 leaf branches with binding SID to the root Tree-SID using the same MVPN
procedures for tree instantiation.  Makes sense and I fully support the
draft concept.  With SR-MPLS you also have the option of using Sandy’s BGP
based multicast for building multicast distribution trees and LHR source
discovery.

https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-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 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> With SR-MPLS for c-multicast signaling over p-tree  ; the only P
tunnel that can be instantiated  prior to this draft is IR, PIM Rosen trees
using existing MVPN procedures or BIER.  Sandy’s BGP multicast draft above
also provides another method of tree instantiation prior to this draft.  So
you are stating that those P tunnel models can the distributed model today
which is why they are not mentioned in this draft.  So now this draft
provides yet another P tree type that now that uses SR natively that can be
instantiated.  What is the benefit of using this draft for tree
instantiation over the other pre existing options.  With this draft you are
natively doing the replication in the forwarding plane with
replication-SID.  Would this drafts tree building method be more
efficient??    SR-MPLS with ldp and RSVP TE removed from the core ; now
reusing the existing MPLS data plane for SR label stacking SRGB labels ;
indexes or absolute labels.  So mLDP is RSVP TE is no longer an alternative
with SR of course once a customer is completely migrated to SR-MPLS.  That
would be the real world SR-MPLS end state use case then an intermediate
migration two ships in the night use case with SR-MPLS and ldp are
coexisting and now the other P tunnel options exist.   I was thinking of
the “SR prefer” option where you shutdown and eventually remove ldp.   I
think you are thinking of  SR-MPLS w/ ldp interworking - with overlay paths
that exist to prefix SID FEC destination or  for an LDP LSP and exist as
two ships in the night - ldp has FEC binding as well for a different prefix
loopback on the egress PE.  So with SR with ldp interworking both SR-MPLS
and ldp can coexist as two ships in the night.  Draft below shows the
SR-MPLS and LDP interoperability within the same MPLS domain as two ships
in the night.  I have not tried overlay of ldp and SR on the same nodes and
having a different FEC loopback for SR from ldp ; so both SR and LDP LSPs
can coexist in the same nodes and same links along the same paths with
different FEC label bindings.  I believe it is possible. For SRv6 and
SR-MPLS also the same can coexist and so really per the drafts below all
three can coexist as 3 ships in the night.  I think with all 3 ; if you do
different nodes and different paths or same nodes different links and
paths,  that will definitely work ; but not sure if you can do same nodes
same paths with different FEC binding for all three flavors.

https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-15

https://datatracker.ietf.org/doc/draft-agrawal-spring-srv6-mpls-interworking/


> 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> Makes sense to use IR in both direction for PIM Birdir trees where
each branch is root and leaf.  Why can’t you do the same IR replication
process methodology with this draft ; same concept and extent the
replication-sid stitching to MP2MP in which case you would not have a
tree-SID since both left and right side of tree would now be MP leaf
branches.  You could use the MVPN type 4 leaf-ad from leaf to discover the
MP branch on the left and right side and do the replication-sid stitching
in both directions to support MP2MP MDTs.  What do you think ; is that a
possibility?

>
> 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> I saw the new tunnel codepoint - TBD

IANA to assign a codepoint [[CREF2: TBD]] for "P2MP tree" in the
   "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types"
   registry.


https://tools.ietf.org/html/draft-parekh-bess-mvpn-sr-p2mp-01



> 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.
>

  Gyan> Understood.  Agreed.

>
> -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
> >
> >
> >
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com