Re: [spring] Understanding the replication draft

["Joel M. Halpern" <[e-mail]>]

I don't even bind if the binding SID behavior is part of the replication 
SID (with different binding results in different directions).  Which 
would seem to allow multi-stage replication even with requirement A.

Allowing a binding SID after the replication SID seems to require that 
the explicit binding SID, t the replicating node, have different 
meanings for different directions.  Or something??

Yours,
Joel

On 7/1/2020 3:42 PM, Alexander Vainshtein 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 <https://aka.ms/ghei36>
> 
> ------------------------------------------------------------------------
> *From:* spring <[e-mail]> on behalf of Robert Raszuk 
> <[e-mail]>
> *Sent:* Wednesday, July 1, 2020, 22:27
> *To:* Rishabh Parekh
> *Cc:* Joel Halpern Direct; [e-mail]
> *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.
> ------------------------------------------------------------------------