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.i...@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.vainsht...@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.vainsht...@ecitele.com > > > -----Original Message----- > From: spring <spring-boun...@ietf.org> On Behalf Of Dhruv Dhody > Sent: Tuesday, July 7, 2020 1:02 PM > To: bruno.decra...@orange.com > Cc: 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.decra...@orange.com> wrote: > > > > Hi Dhruv, > > > > > -----Original Message----- > > > From: spring [mailto:spring-boun...@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%2Fdoc%2Fdraft-voyer-pim-sr-p2mp-policy%2F > > > [2] > > > https://clicktime.symantec.com/3LtBxbxRK3NkuKYc3FC7rr46H2?u=https%3A > > > %2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fpim%2FYyF7I02aaRtpZngf7uTn > > > o69IB90%2F > > > > > > > > > > > > On Thu, Jul 2, 2020 at 12:05 PM Rishabh Parekh <risha...@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.i...@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 > > > > > <risha...@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 > > > > > <rob...@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 > > > > > https://clicktime..symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https > <https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https> > > > > > %3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > > > > https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3 > > > > A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A% > > > 2F%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 > > 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 > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
