Sasha, I agree with Robert. Building MDTs for services is covered in a separate draft in BESS: https://datatracker.ietf.org/doc/draft-parekh-bess-mvpn-evpn-sr-p2mp/
-Rishabh On Wed, Jul 1, 2020 at 2:56 PM Robert Raszuk <rob...@raszuk.net> wrote: > > Hi Alexander, > > Do we really know how to build MDTs as source routed chains ? > > If that is the goal here IMHO it deserves a whole separate document .... > > In general when we replicate we take a packet and copy it to interfaces A, B > ... Z. That's a local rule I presume executed for flows containing R-SID-n. > But we just can't send the packet with identical list of SIDs from that point > on any outgoing interface as results will be rather poor. > > We need custom list for each outbound interface and that is something I am > not seeing in the draft. Till this is explained I would keep thinking that > building MDTs should be more of as control plane task. > > Thx. > R. > > On Wed, Jul 1, 2020 at 9:42 PM Alexander Vainshtein > <alexander.vainsht...@rbbn.com> wrote: >> >> Robert, Rishabh and all, >> I concur with Robert but would like to add that Option A woild effectively >> eliminate the possibility of building MDTs with more than one level using >> Replication Segments. >> >> Which is probably not the intent of the draft. >> >> My 2c. >> >> Get Outlook for Android >> >> ________________________________ >> From: spring <spring-boun...@ietf.org> on behalf of Robert Raszuk >> <rob...@raszuk.net> >> Sent: Wednesday, July 1, 2020, 22:27 >> To: Rishabh Parekh >> Cc: Joel Halpern Direct; spring@ietf.org >> Subject: Re: [spring] Understanding the replication draft >> >> 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. >> >> >> >> ________________________________ >> 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
