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 <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
