>> 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. We are working onthe next revision of the draft that will clarify some text and illustrate and example. We shall post it soon. -Rishabh On Tue, Jul 7, 2020 at 2:42 AM <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://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/ > > [2] > > https://mailarchive.ietf.org/arch/msg/pim/YyF7I02aaRtpZngf7uTno69IB90/ > > > > > > > > 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://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 > > _________________________________________________________________________________________________________________________ > > 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://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
