Re: [spring] Understanding the replication draft

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Wed, 15 July 2020 04:39 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF923A0EA9 for <spring@ietfa.amsl.com>; Tue, 14 Jul 2020 21:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_BTC_ID=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 SlTOHvXrEbM5 for <spring@ietfa.amsl.com>; Tue, 14 Jul 2020 21:39:05 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037293A0EA8 for <spring@ietf.org>; Tue, 14 Jul 2020 21:39:05 -0700 (PDT)
Received: from lhreml714-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 686789B2F8DCC80A04A4; Wed, 15 Jul 2020 05:39:02 +0100 (IST)
Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 15 Jul 2020 05:39:01 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 15 Jul 2020 12:38:58 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Wed, 15 Jul 2020 12:38:58 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: Rishabh Parekh <rishabhp@gmail.com>
CC: Jeff Tantsura <jefftant.ietf@gmail.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "spring@ietf.org" <spring@ietf.org>, "Alexander Vainshtein" <Alexander.Vainshtein@rbbn.com>
Thread-Topic: [spring] Understanding the replication draft
Thread-Index: AQHWTmMsVR0gULMMHUCpT/9wCVxmXajyYFoAgAAEzYCAACk7gIAAChGAgAADa4CAAFaeAIAAYGGAgAbjqQCAASxYgIAABXQAgAA+igCAAH3UgIAErpOAgAY21tCAAAy3gIAA/POQ
Date: Wed, 15 Jul 2020 04:38:58 +0000
Message-ID: <f6f94fddd4ca4e9dac51db4742b06bc9@huawei.com>
References: <94415742-fc4e-1774-bf96-01eac3672bfb@joelhalpern.com> <CABjMoXYCsXb-iP55PsNWHBG187Lm7-2PXfgD3qRn_aD6ppDuMw@mail.gmail.com> <b3aaaa47-af61-6fc0-1086-bfd59efea061@joelhalpern.com> <CABjMoXY5S1Bx3rQM-0eyJfzh9iOgAZoGshs1wFqebnkVZ++G0w@mail.gmail.com> <CAOj+MMFsjRCgbY1V5idoKmqKR7W5gwM7ui7cp6W12GQm0XEHyQ@mail.gmail.com> <CABjMoXbka+L3STNd4EPOfT5KA35ECZQt3jk=g0m=GU9VUj9csA@mail.gmail.com> <baaf7a09-f20d-4863-b7f7-36118e11cc4b@Spark> <CABjMoXZaiED+++2ij6CB_MH6dqGgs=t829XgsYy+6HHC69SDrQ@mail.gmail.com> <CAB75xn7f0RaMPhmN2KH26Z--8pp-ioGCMGSC+0MOx1T=Ugp+xg@mail.gmail.com> <32104_1594114929_5F044371_32104_68_5_53C29892C857584299CBF5D05346208A48EC8CCE@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAB75xn6CQsTEtDfR_UoRQCfgYUAFcjDyxBn1SidZx2EwK+9WTA@mail.gmail.com> <DB7PR03MB4505877740699D5EFD4EA64A9D660@DB7PR03MB4505.eurprd03.prod.outlook.com> <3d5c2f1b-d033-41ca-a59d-6c74addcc08c@Spark> <CABjMoXZ=+g0+4tv=U_nG+_85h830gfG7D7mQuAw09wQOvtgTWw@mail.gmail.com> <c9f68faa7ff8480c832cdc60bb2c98b0@huawei.com> <CABjMoXYbNdjJLQs8y+f8oUgKVKs1psiYK7j9SZW_SbPoiJtYdw@mail.gmail.com>
In-Reply-To: <CABjMoXYbNdjJLQs8y+f8oUgKVKs1psiYK7j9SZW_SbPoiJtYdw@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.118]
Content-Type: multipart/alternative; boundary="_000_f6f94fddd4ca4e9dac51db4742b06bc9huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/9t2mZmFEUBOoh9hLdJ8Hioy_Jq0>
Subject: Re: [spring] Understanding the replication draft
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2020 04:39:09 -0000

Hi Rishabh,

Thank you very much for the reply.
The words you used like P2MP service/P2MP transport, upstream label/DCB, last SID/BoS  and their distinctions all match my dictionary, so it’s now very clear to me. Sincerely appreciate!

I have some further comments in detail:


1)       About the distinction of Replication-ID and Replication-SID, and their usage.
If there is an SID block specially reserved for the P2MP Transport on each of the Replication Node, and such SID block (on each Replication Node) is advertised through west-east protocol like IGP/BGP,
and then the north-south controller (like PCE) can use the “Replication-ID” and “Node-ID” only, but don’t need to use “Replication-SID” when populating the “Tree” information to each “Replication Node” ?
In that way, the Controller doesn’t need to allocate (and manage) each of the Replication-SID (Say 1000 Replication-SID)  for  each Replication Node (Say 100 nodes).


2)       About the Replication Segment illustration.
The rev-04 add a section “Illustration of a Replication Segment” in appendix, it is very clear and useful.
To me, the “Replication State” is more like a “forwarding state”, and I think it will be helpful to understand the whole solution if:
a) there is a description/Illustration about the building procedure of the “forwarding state” ---- What’s the information each Replication Node receives from the controller, and how each node builds its own forwarding state.
b) there is a description/Illustration about the processing of multicast packet on the whole path of the P2MP tree.


3)       About the applicability of SR-MPLS and SRv6.
The rev-04 says “Replication segments apply equally to both SR-MPLS and SRv6 instantiations of Segment Routing.”.
I am not sure if this document will cover SRv6 as well, but if it does, then I would like to see the same level of consideration as SR-MPLS.

Thanks,
Jingrong


From: Rishabh Parekh [mailto:rishabhp@gmail.com]
Sent: Wednesday, July 15, 2020 4:25 AM
To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>om>; Dhruv Dhody <dhruv.ietf@gmail.com>om>; bruno.decraene@orange.com; spring@ietf.org; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Subject: Re: [spring] Understanding the replication draft

Jingrong,
As I had explained to Jeff Tantsura earlier in the thread, with P2MP services realized by P2MP trees, VPN label is NOT part of the label stack since egress (leaf nodes of P2MP trees) of the P2MP service MAY have different VPN labels for same context. For P2MP services, it is normal to use the top transport label (Replication SID in this case) as implicit context for the service. Of course, this implies one-to-one association between P2MP transport and service.

There are techniques, using upstream label allocation or DCB (domain wide context blocks), where the same VPN label can be assigned to the service on all the egress nodes. In this case, the P2MP transports can be shared across P2MP services (at a set of egress nodes) and the VPN label can appear after the Replication SID as we have indicated in the PIM WG draft. But, the VPN label is not a SID and, IMO, the statement "Replication SID must be last SID...." still holds but it is not at the bottom of the stack. We can clarify this when we publish the WG document.

-Rishabh

On Tue, Jul 14, 2020 at 4:55 AM Xiejingrong (Jingrong) <xiejingrong@huawei.com<mailto:xiejingrong@huawei.com>> wrote:
Hi

The rev-04 says “The Replication SID MUST be the last SID (at the bottom of stack for SR-MPLS) in a packet that is steered out from a Replication node of a Replication Segment.”.

I feel a little hard to understand ……

My question is: Can an “MPLS packet” be carried over the P2MP policy ? say a packet like this: { Replication SID, (VPN Label, IPv4/IPv6 C-multicast packet) } ?

In my understanding, with an imagined topology comprising of Replication Node R1/R2/R3/R4, the picture is like this:

The Replication Node R2 receives such a packet (from R1), sees the Replication SID<R2> on the “Top” of the label stack,  performs the corresponding action of “replication”,  replicates the packet to downstream Replication Nodes R3 and R4, SWAPs the Replication SID<R2> to Replication SID<R3> and Replication SID<R4> respectively.

The Replication Node R3 receives the packet { Replication SID<R3>, (VPN Label, IPv4/IPv6 C-multicast packet) }.

The Replication Node R4 receives the packet { Replication SID<R4>, (VPN Label, IPv4/IPv6 C-multicast packet) }.

Thanks
Jingrong

From: spring [mailto:spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>] On Behalf Of Rishabh Parekh
Sent: Saturday, July 11, 2020 4:46 AM
To: Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>
Cc: Dhruv Dhody <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>>; bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>; spring@ietf.org<mailto:spring@ietf.org>; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>
Subject: Re: [spring] Understanding the replication draft

All,
We have posted revision 04<https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-04> of the draft. This addresses comments on this thread and adds an example illustrating replication segment. Diff from rev 03:  https://tinyurl.com/y96ueb9h

Some WG  members also wanted to understand how Replication segments are stitched together to form a P2MP tree based on SR P2MP policy in the PIM draft. We have posted revision 02<https://tools.ietf.org/html/draft-voyer-pim-sr-p2mp-policy-02> of PIM P2MP policy draft that adds examples of how these things tie together. I hope that helps clarify the relationship. Diff from rev 01: https://tinyurl.com/yban2jp6

Please review,
-Rishabh

On Tue, Jul 7, 2020 at 2:16 PM Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>> wrote:
Thanks Rishabh!
+1 to the above comments and looking forward to the updated draft.

Cheers,
Jeff
On Jul 7, 2020, 7:35 AM -0700, Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>, wrote:
Dhruv, Bruno and all,
Regarding the statement " What is missing in the spring I-D is some very high level discussion in terms of architecture on how replication segment and SR P2MP policy come together" - I cannot agree more.

My 2c,
Sasha

Office: +972-39266302
Cell: +972-549266302
Email: Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>


-----Original Message-----
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Dhruv Dhody
Sent: Tuesday, July 7, 2020 1:02 PM
To: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] Understanding the replication draft

Hi Bruno,

Yes, thanks! I was just making sure that we have an agreement that PIM is the right place to define SR P2MP Policy.

What is missing in the spring I-D is some very high level discussion in terms of architecture on how replication segment and SR P2MP policy come together. The current I-D tries to define a replication segment as an independent entity that could be used on its own but it makes it difficult to visualize without some high level text or an example.

Thanks!
Dhruv

On Tue, Jul 7, 2020 at 3:12 PM <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:
>
> Hi Dhruv,
>
> > -----Original Message-----
> > From: spring [mailto:spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>] On Behalf Of Dhruv
> > Dhody
> > Subject: Re: [spring] Understanding the replication draft
> >
> > Hi WG,
> >
> > Reading the I-D and based on the discussion on this thread I believe
> > more description is required. As Joel pointed out, clarity on what
> > is legal/illegal (or out of scope for now) is needed.
>
> I leave this for the authors to reply.
>
> > I have no strong opinion if that needs to be done before or after adoption!
> >
> > I do not follow PIM closely and just realized that the SR P2MP
> > Policy in the PIM I-D [1] is adopted by the PIM WG, but not yet posted [2].
> > I wanted to make sure that it has been decided that PIM is the right
> > place to define SR P2MP policy (discussed either in the WG and/or
> > between chairs/AD)?
>
> draft-voyer-pim-sr-p2mp-policy-00 is to be worked in the PIM WG.
> The PIM WG is waiting for the SPRING WG to adopt draft-voyer-spring-sr-replication-segment, since the -pim- document has a dependency on the -spring- document.
>
> Quoting the PIM chairs: "We have solid support to adopt this draft.. [...] We are waiting to hear back from the spring chairs as to the wg status of the local replication draft of which your draft is dependent.. So please hold off on submitting the new draft-ietf-pim-sr-p2mp-policy until they give us the green light."
>
> Does this answer your question?
>
> --Bruno
>
> > Thanks!
> > Dhruv
> >
> > [1]
> > https://clicktime.symantec.com/36sxrNPFssiaB8jE9mzzZDd6H2?u=https%3A
> > %2F%2Fdatatracker.ietf.org<http://2Fdatatracker.ietf.org>%2Fdoc%2Fdraft-voyer-pim-sr-p2mp-policy%2F
> > [2]
> > https://clicktime.symantec.com/3LtBxbxRK3NkuKYc3FC7rr46H2?u=https%3A
> > %2F%2Fmailarchive.ietf.org<http://2Fmailarchive.ietf.org>%2Farch%2Fmsg%2Fpim%2FYyF7I02aaRtpZngf7uTn
> > o69IB90%2F
> >
> >
> >
> > On Thu, Jul 2, 2020 at 12:05 PM Rishabh Parekh <rishabhp@gmail...com<mailto:rishabhp@gmail...com>>
> > wrote:
> > >
> > > Jeff,
> > > Your explanation of distinct Transport SIDs and service labels
> > > (which appear at BoS) applies to Point-to-Point services. Same
> > > model can be applied when a Point-to-Multipoint service is
> > > realized by one end-to-end replication segment; "Downstream
> > > Replication SID" as specified in draft is effectively the service
> > > label at a specific downstream node of a Replication segment with
> > > Transport SIDs imposed on top to take replicated packet to that node.
> > >
> > > However, when a Point-to-Multipoint service is over replication
> > > segments stitched together to form a P2MP tree, as described in
> > > PIM WG draft, this model no longer holds since all service egress
> > > nodes would have to agree on one common service label. So P2MP
> > > services implicitly map the P2MP transport label (Replication SID
> > > at BoS in this case) to the P2MP service. Of course, this implies
> > > one-to-one association between a P2MP service and a P2MP
> > > transport. There are techniques to share one P2MP transport across
> > > different P2MP services using either upstream assigned label or a
> > > global context from "Domain-wide Common Block"
> > > (draft-ietf-bess-mvpn-evpn-aggregation-label). These and other
> > > gory details are described in Section 2 of PIM WG draft and to
> > > some extent in BESS MVPN-EVPN draft.
> > >
> > > -Rishabh
> > >
> > > On Wed, Jul 1, 2020 at 5:50 PM Jeff Tantsura
> > > <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>
> > wrote:
> > > >
> > > > Rishabh,
> > > >
> > > > Transport SID with a service on top can’t be a BoS label,
> > > > there’s s service
> > label below, since a service is associated with a particular node,
> > there would be at least a N-SID associated with the service node.
> > > > It seems like B-SID behavior is the correct one, when R-SID is
> > > > looked up
> > and popped, it would yield: replication (as programmed by a
> > controller, since there’s no state) + new label stack associated
> > with the new, post replication/branching path that is imposed on top
> > of existing label stack, so service label ( + optionally more transport labels) are preserved.
> > > >
> > > > Cheers,
> > > > Jeff
> > > > On Jul 1, 2020, 12:40 PM -0700, Rishabh Parekh
> > > > <rishabhp@gmail.com<mailto:rishabhp@gmail.com>>,
> > wrote:
> > > >
> > > > Robert,
> > > >
> > > > A) Firmly state that replication SID MUST be the last one on the
> > > > stack
> > > > B) Instead of real SID after the replication SID provide a
> > > > binding SID which
> > locally will be mapped to a different SID list imposed to each replicated flow.
> > > >
> > > >
> > > > We would be fine with A), but we don't want to exclude
> > > > possibility of something like what you describe in B.
> > > >
> > > > -Rishabh
> > > >
> > > > On Wed, Jul 1, 2020 at 12:27 PM Robert Raszuk
> > > > <robert@raszuk.net<mailto:robert@raszuk.net>>
> > wrote:
> > > >
> > > >
> > > > Hi Rishabh,
> > > >
> > > > Of course, care must be
> > > > taken to avoid the "explosion" as you describe it.. G-SID-2 has
> > > > to map to a unique node; for example, it may be an Anycast-SID
> > > > that takes packet to distinct nodes from each of the downstream
> > > > node, or the downstream nodes can be border nodes connecting to
> > > > other segment routing domains where G-SID-2 resolves to distinct
> > > > nodes in each domain.
> > > >
> > > >
> > > > I think you are stretching it too thin.
> > > >
> > > > See even if G-SID-2 is anycast SID you have zero assurance that
> > > > physical
> > nodes packets will land on would be at all diverse.
> > > >
> > > > Likewise crossing domains yet providing identical global SID now
> > > > to be a
> > different node in each such domain to me is not a realistic example.
> > > >
> > > > I think we have two options:
> > > >
> > > > A) Firmly state that replication SID MUST be the last one on the
> > > > stack
> > > >
> > > > B) Instead of real SID after the replication SID provide a
> > > > binding SID which
> > locally will be mapped to a different SID list imposed to each replicated flow.
> > > >
> > > > What is currently in the draft seems to be very counterintuitive
> > > > and IMHO
> > will result in operational difficulties.
> > > >
> > > > Thx a lot,
> > > > R.
> > > >
> > > >
> > > > _______________________________________________
> > > > spring mailing list
> > > > spring@ietf.org<mailto:spring@ietf.org>
> > > > https://clicktime..symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https<https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https>
> > > > %3A%2F%2Fwww.ietf.org<http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring
> > >
> > > _______________________________________________
> > > spring mailing list
> > > spring@ietf.org<mailto:spring@ietf.org>
> > > https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3<https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%253>
> > > A%2F%2Fwww.ietf.org<http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.org<mailto:spring@ietf.org>
> > https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A%<https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A%25>
> > 2F%2Fwww.ietf..org<http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>

_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
________________________________
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc.. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
________________________________
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring