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
